From 4c1ba9dda796b8cd58e63400f861b0f5f090eefa Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 15:51:59 -0700
Subject: [PATCH 1/9] Use HTML entity for asterisks within manual added HTML
 tags

---
 .../monitoring-alerting/expression/expression.md | 16 ++++++++--------
 .../monitoring-alerting/expression/expression.md | 16 ++++++++--------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/docs/en/monitoring-alerting/expression/expression.md b/docs/en/monitoring-alerting/expression/expression.md
index 60eb9fc2b92..d0201d1f934 100644
--- a/docs/en/monitoring-alerting/expression/expression.md
+++ b/docs/en/monitoring-alerting/expression/expression.md
@@ -111,15 +111,15 @@ For more information about querying the Prometheus time series database, refer t
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
-| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
+| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
 
 ### Cluster Network I/O
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
-| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
+| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
 
 # Node Metrics
 
@@ -162,15 +162,15 @@ For more information about querying the Prometheus time series database, refer t
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
-| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
+| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
 
 ### Node Network I/O
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
-| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
+| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
 
 # Etcd Metrics
 
diff --git a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/expression/expression.md b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/expression/expression.md
index 5b170407ef7..40a128118dd 100644
--- a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/expression/expression.md
+++ b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/expression/expression.md
@@ -118,15 +118,15 @@ For more information about querying the Prometheus time series database, refer t
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
-| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
+| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
 
 ### Cluster Network I/O
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m])) by (instance)</code></td></tr></table> |
-| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
+| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |
 
 # Node Metrics
 
@@ -169,15 +169,15 @@ For more information about querying the Prometheus time series database, refer t
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
-| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
+| Summary | <table><tr><td>receive-dropped</td><td><code>sum(rate(node_network_receive_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-errs</td><td><code>sum(rate(node_network_receive_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>receive-packets</td><td><code>sum(rate(node_network_receive_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-dropped</td><td><code>sum(rate(node_network_transmit_drop_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-errs</td><td><code>sum(rate(node_network_transmit_errs_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit-packets</td><td><code>sum(rate(node_network_transmit_packets_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
 
 ### Node Network I/O
 
 | Catalog | Expression |
 | --- | --- |
-| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
-| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.* &#124; docker.* &#124; flannel.* &#124; cali.* &#124; cbr.*",instance=~"$instance"}[5m]))</code></td></tr></table> |
+| Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
+| Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |
 
 # Etcd Metrics
 

From 997e4a09523f91e0ab3467a066615395bc23a6f5 Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 15:57:38 -0700
Subject: [PATCH 2/9] Image does not render without newline

---
 .../backups/docker-installs/docker-backups/docker-backups.md   | 1 +
 .../backups/docker-installs/docker-restores/docker-restores.md | 3 ++-
 .../single-node-upgrades/single-node-upgrades.md               | 1 +
 .../en/backups/backup/docker-backups/docker-backups.md         | 1 +
 .../en/backups/restore/docker-restores/docker-restores.md      | 1 +
 .../single-node-upgrades/single-node-upgrades.md               | 1 +
 .../backups/docker-installs/docker-backups/docker-backups.md   | 1 +
 .../backups/docker-installs/docker-restores/docker-restores.md | 1 +
 .../single-node-upgrades/single-node-upgrades.md               | 1 +
 .../backups/docker-installs/docker-backups/docker-backups.md   | 1 +
 .../backups/docker-installs/docker-restores/docker-restores.md | 1 +
 .../single-node-upgrades/single-node-upgrades.md               | 1 +
 12 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/docs/en/backups/docker-installs/docker-backups/docker-backups.md b/docs/en/backups/docker-installs/docker-backups/docker-backups.md
index d3e8118e56c..f4b9eb8b9ea 100644
--- a/docs/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/docs/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -19,6 +19,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/docs/en/backups/docker-installs/docker-restores/docker-restores.md b/docs/en/backups/docker-installs/docker-restores/docker-restores.md
index b89607887be..2c5fd2246f2 100644
--- a/docs/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/docs/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -21,6 +21,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
@@ -51,7 +52,7 @@ Using a [backup]({{<baseurl>}}/rancher/v2.6/en/backups/docker-installs/docker-ba
 1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
 
     :::danger
-    
+
     This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
 
     :::
diff --git a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 6730f3090ca..f1f89be7585 100644
--- a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -42,6 +42,7 @@ docker ps
 Write down or copy this information before starting the upgrade.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
index e20ea42087a..ffa4ccf456a 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
@@ -38,6 +38,7 @@ docker ps
 Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
index 1dd88ae4ee2..7b6fdb6c549 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
@@ -26,6 +26,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 32a49cebf14..7c2e5088c68 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -42,6 +42,7 @@ docker ps
 Write down or copy this information before starting the upgrade.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
index 8ceabd8db84..a145b87e045 100644
--- a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -27,6 +27,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
index fd4ddac530c..54fbdca323c 100644
--- a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -26,6 +26,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 061073a4de8..ffd17a232a8 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -43,6 +43,7 @@ docker ps
 Write down or copy this information before starting the upgrade.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
index d3e8118e56c..f4b9eb8b9ea 100644
--- a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -19,6 +19,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
index 8fa8b8cb302..f853fe124e3 100644
--- a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -21,6 +21,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index f20a97ea617..ba9e5589074 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -38,6 +38,7 @@ docker ps
 Write down or copy this information before starting the upgrade.
 
 <sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
 | Placeholder                | Example                    | Description                                               |

From c7c1266582109f37e4497d69217986de8d0560e8 Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 16:43:37 -0700
Subject: [PATCH 3/9] Inline code via backtick does not render when HTML tag
 present on line. Use <code> and <tag> instead

---
 .../docker-installs/docker-backups/docker-backups.md       | 4 ++--
 .../docker-installs/docker-restores/docker-restores.md     | 2 +-
 .../single-node-rollbacks/single-node-rollbacks.md         | 7 +++----
 .../single-node-upgrades/single-node-upgrades.md           | 4 ++--
 .../en/backups/backup/docker-backups/docker-backups.md     | 4 ++--
 .../en/backups/restore/docker-restores/docker-restores.md  | 2 +-
 .../single-node-rollbacks/single-node-rollbacks.md         | 5 ++---
 .../single-node-upgrades/single-node-upgrades.md           | 4 ++--
 .../docker-installs/docker-backups/docker-backups.md       | 4 ++--
 .../docker-installs/docker-restores/docker-restores.md     | 2 +-
 .../single-node-rollbacks/single-node-rollbacks.md         | 5 ++---
 .../single-node-upgrades/single-node-upgrades.md           | 4 ++--
 .../docker-installs/docker-backups/docker-backups.md       | 4 ++--
 .../docker-installs/docker-restores/docker-restores.md     | 2 +-
 .../single-node-rollbacks/single-node-rollbacks.md         | 5 ++---
 .../single-node-upgrades/single-node-upgrades.md           | 4 ++--
 16 files changed, 29 insertions(+), 33 deletions(-)

diff --git a/docs/en/backups/docker-installs/docker-backups/docker-backups.md b/docs/en/backups/docker-installs/docker-backups/docker-backups.md
index f4b9eb8b9ea..274a0ece9ea 100644
--- a/docs/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/docs/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -18,7 +18,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -50,7 +50,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
     docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
     ```
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
 
     ```
     docker run  --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
diff --git a/docs/en/backups/docker-installs/docker-restores/docker-restores.md b/docs/en/backups/docker-installs/docker-restores/docker-restores.md
index 2c5fd2246f2..3413be1bb9b 100644
--- a/docs/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/docs/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -20,7 +20,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
diff --git a/docs/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md b/docs/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
index d056b93a415..87cdd19514d 100644
--- a/docs/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+++ b/docs/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
@@ -20,8 +20,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
-![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
 
 | Placeholder                | Example                    | Description                                             |
 | -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -81,9 +80,9 @@ Rolling back to a previous version of Rancher destroys any changes made to Ranch
     rancher/rancher:<PRIOR_RANCHER_VERSION>
     ```
     Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-    
+
     :::danger
-    
+
     **_Do not_** stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
 
     :::
diff --git a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index f1f89be7585..8000be1c114 100644
--- a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -41,7 +41,7 @@ docker ps
 
 Write down or copy this information before starting the upgrade.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -84,7 +84,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
 
 # 2. Create a backup tarball
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
 
     This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
index ffa4ccf456a..d1ae9b2816b 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/backup/docker-backups/docker-backups.md
@@ -37,7 +37,7 @@ docker ps
 
 Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -69,7 +69,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
     docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
     ```
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder.
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder.
 
     ```
     docker run  --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
index 7b6fdb6c549..6d557aa5111 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/backups/restore/docker-restores/docker-restores.md
@@ -25,7 +25,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
index 2d116119266..edd7af34feb 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
@@ -23,8 +23,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
-![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
 
 | Placeholder                | Example                    | Description                                             |
 | -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -78,7 +77,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
     -p 80:80 -p 443:443 \
     rancher/rancher:<PRIOR_RANCHER_VERSION>
     ```
-    
+
     >**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
 
 1.  Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 7c2e5088c68..be22dd5f101 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -41,7 +41,7 @@ docker ps
 
 Write down or copy this information before starting the upgrade.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -84,7 +84,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
 
 # 2. Create a backup tarball
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
 
     This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
 
diff --git a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
index a145b87e045..082be2ff661 100644
--- a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -26,7 +26,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -58,7 +58,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
     docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
     ```
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
 
     ```
     docker run  --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
diff --git a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
index 54fbdca323c..ea57c9b7965 100644
--- a/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.5/v2.5/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -25,7 +25,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
index 11189b9dd6e..36841a0c738 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
@@ -24,8 +24,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
-![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
 
 | Placeholder                | Example                    | Description                                             |
 | -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -81,7 +80,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
     rancher/rancher:<PRIOR_RANCHER_VERSION>
     ```
     As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
-    
+
     >**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
 
 1.  Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index ffd17a232a8..b8f35c99dd2 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -42,7 +42,7 @@ docker ps
 
 Write down or copy this information before starting the upgrade.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -85,7 +85,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
 
 # 2. Create a backup tarball
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
 
     This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
 
diff --git a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
index f4b9eb8b9ea..274a0ece9ea 100644
--- a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
+++ b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-backups/docker-backups.md
@@ -18,7 +18,7 @@ In this command, `<DATE>` is a placeholder for the date that the data container
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -50,7 +50,7 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
     docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
     ```
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data-<DATE>`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`). Use the following command, replacing each placeholder:
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-&lt;DATE&gt;</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>). Use the following command, replacing each placeholder:
 
     ```
     docker run  --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
diff --git a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
index f853fe124e3..23e002610c5 100644
--- a/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
+++ b/versioned_docs/version-2.6/v2.6/en/backups/docker-installs/docker-restores/docker-restores.md
@@ -20,7 +20,7 @@ In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are e
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
index 4e27d103300..00e4e1bd25b 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-rollbacks/single-node-rollbacks.md
@@ -20,8 +20,7 @@ In this command, `<PRIOR_RANCHER_VERSION>` is the version of Rancher you were ru
 
 Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>`</sup>
-![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;PRIOR_RANCHER_VERSION&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref-2.png)
 
 | Placeholder                | Example                    | Description                                             |
 | -------------------------- | -------------------------- | ------------------------------------------------------- |
@@ -77,7 +76,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
     rancher/rancher:<PRIOR_RANCHER_VERSION>
     ```
     Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-    
+
     >**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
 
 1.  Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index ba9e5589074..96a881dcaa6 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -37,7 +37,7 @@ docker ps
 
 Write down or copy this information before starting the upgrade.
 
-<sup>Terminal `docker ps` Command, Displaying Where to Find `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>`</sup>
+<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code>&lt;RANCHER_CONTAINER_TAG&gt;</code> and <code>&lt;RANCHER_CONTAINER_NAME&gt;</code></sup>
 
 ![Placeholder Reference]({{<baseurl>}}/img/rancher/placeholder-ref.png)
 
@@ -80,7 +80,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
 
 # 2. Create a backup tarball
 
-1. <a id="tarball"></a>From the data container that you just created (`rancher-data`), create a backup tarball (`rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`).
+1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data</code>), create a backup tarball (<code>rancher-data-backup-&lt;RANCHER_VERSION&gt;-&lt;DATE&gt;.tar.gz</code>).
 
     This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder.
 

From 54f9da1dfa2f7fbc3d4067d2542aabdd349d753d Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 16:53:33 -0700
Subject: [PATCH 4/9] Convert line break tags causing errors

---
 .../migrating-rancher/migrating-rancher.md    |  8 +++----
 docs/en/deploy-across-clusters/fleet/fleet.md | 12 +++++-----
 .../how-monitoring-works.md                   | 12 +++++-----
 .../creating-credentials.md                   |  6 ++---
 .../en/faq/upgrades-to-2x/upgrades-to-2x.md   | 20 ++++++++---------
 .../creating-apps/creating-apps.md            |  2 +-
 .../install-rancher/install-rancher.md        |  4 ++--
 .../populate-private-registry.md              | 18 +++++++--------
 .../testing-hpa/testing-hpa.md                |  2 +-
 .../migrating-rancher/migrating-rancher.md    | 14 ++++++------
 .../iscsi-volumes/iscsi-volumes.md            |  6 ++---
 .../testing-hpa/testing-hpa.md                |  2 +-
 .../how-monitoring-works.md                   | 12 +++++-----
 .../en/deploy-across-clusters/fleet/fleet.md  | 12 +++++-----
 .../v2.6/en/faq/dockershim/dockershim.md      | 20 ++++++++---------
 versioned_docs/version-2.6/v2.6/en/faq/faq.md | 22 +++++++++----------
 .../networking/cni-providers/cni-providers.md | 12 +++++-----
 .../v2.6/en/faq/security/security.md          |  2 +-
 .../creating-apps/creating-apps.md            |  4 ++--
 .../install-rancher/install-rancher.md        |  6 ++---
 .../requirements/dockershim/dockershim.md     | 20 ++++++++---------
 .../how-monitoring-works.md                   | 12 +++++-----
 .../v2.6/en/pipelines/config/config.md        |  8 +++----
 23 files changed, 118 insertions(+), 118 deletions(-)

diff --git a/docs/en/backups/migrating-rancher/migrating-rancher.md b/docs/en/backups/migrating-rancher/migrating-rancher.md
index be138345663..e18f04fcf16 100644
--- a/docs/en/backups/migrating-rancher/migrating-rancher.md
+++ b/docs/en/backups/migrating-rancher/migrating-rancher.md
@@ -30,7 +30,7 @@ helm repo update
 helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
 helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
 ```
-</br>
+<br/>
 For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
 ```
 --set image.repository $REGISTRY/rancher/backup-restore-operator
@@ -70,7 +70,7 @@ data:
 
 This secret can be created in any namespace; with the above example, it will get created in the default namespace.
 
-In the Restore custom resource, `prune` must be set to false. 
+In the Restore custom resource, `prune` must be set to false.
 
 Create a Restore custom resource like the example below:
 
@@ -96,11 +96,11 @@ spec:
 
 :::note Important:
 
-The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:  
+The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
 
 :::
 
-1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:   
+1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
 ```
 kubectl create secret generic encryptionconfig \
   --from-file=./encryption-provider-config.yaml \
diff --git a/docs/en/deploy-across-clusters/fleet/fleet.md b/docs/en/deploy-across-clusters/fleet/fleet.md
index 1b129ee97f0..c1502c71664 100644
--- a/docs/en/deploy-across-clusters/fleet/fleet.md
+++ b/docs/en/deploy-across-clusters/fleet/fleet.md
@@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
 
 1. Click **☰ > Continuous Delivery**.
 
-1. Select your namespace at the top of the menu, noting the following: 
-    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. 
-    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. 
+1. Select your namespace at the top of the menu, noting the following:
+    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
+    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
     - You can then manage clusters by clicking on **Clusters** on the left navigation bar.
 
-1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. 
+1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
 
 1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
 
@@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts
 # Troubleshooting
 
 ---
-* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. 
+* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
 
-* **Temporary Workaround:** </br>
+* **Temporary Workaround:** <br/>
 By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
 
 ---
diff --git a/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
index 30b19cdbc66..fcd70f138e8 100644
--- a/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
+++ b/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
 - Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
 `kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
 
-- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet. 
-    
+- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
+
 - We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
 
-1. The PushProx Client establishes an outbound connection with the PushProx Proxy.    
+1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
 1. The client then polls the proxy for scrape requests that have come into the proxy.
 1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
 1. The client scrapes the internal component.
 1. The internal component responds by pushing metrics back to the proxy.
-    
 
-<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
+
+<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>
 
 ![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)
 
@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
 ### Alerts Forwarded by alertingDrivers
 
 When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
-    
+
 ### Routing Alerts to Receivers
 
 Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md
index ce7a1fe5d3a..1a3a57d155b 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md
@@ -11,10 +11,10 @@ The following table lists the permissions required for the vSphere user account:
 
 | Privilege Group       | Operations  |
 |:----------------------|:-----------------------------------------------------------------------|
-| Datastore             | AllocateSpace </br> Browse </br> FileManagement (Low level file operations) </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
+| Datastore             | AllocateSpace <br/> Browse <br/> FileManagement (Low level file operations) <br/> UpdateVirtualMachineFiles <br/> UpdateVirtualMachineMetadata |
 | Network               | Assign |
 | Resource              | AssignVMToPool |
-| Virtual Machine       | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
+| Virtual Machine       | Config (All) <br/> GuestOperations (All) <br/> Interact (All) <br/> Inventory (All) <br/> Provisioning (All) |
 
 The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:
 
@@ -37,7 +37,7 @@ The following steps create a role with the required privileges and then assign i
 7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
 
     {{< img "/img/rancher/globalpermissionuser.png" "image" >}}
-    
+
     {{< img "/img/rancher/globalpermissionrole.png" "image" >}}
 
 **Result:** You now have credentials that Rancher can use to manipulate vSphere resources.
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md
index db5cc1e85b3..bae4da16a67 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md
@@ -13,25 +13,25 @@ This page contains frequently asked questions about the changes between Rancher
 
 Rancher v2.x is a complete container management platform built 100% on Kubernetes leveraging its Custom Resource and Controller framework.  All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC.
 
-<br>
+<br/>
 
 **Do you plan to implement upstream Kubernetes, or continue to work on your own fork?**
 
 We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream.
 
-<br>
+<br/>
 
 **Does this release mean that we need to re-train our support staff in Kubernetes?**
 
 Yes.  Rancher will offer the native Kubernetes functionality via `kubectl` but will also offer our own UI dashboard to allow you to deploy Kubernetes workload without having to understand the full complexity of Kubernetes.  However, to fully leverage Kubernetes, we do recommend understanding Kubernetes.  We do plan on improving our UX with subsequent releases to make Kubernetes easier to use.
 
-<br>
+<br/>
 
 **Is a Rancher compose going to make a Kubernetes pod? Do we have to learn both now? We usually use the filesystem layer of files, not the UI.**
 
 No.  Unfortunately, the differences were enough such that we cannot support Rancher compose anymore in 2.x.  We will be providing both a tool and guides to help with this migration.
 
-<br>
+<br/>
 
 **If we use Kubernetes native YAML files for creating resources, should we expect that to work as expected, or do we need to use Rancher/Docker compose files to deploy infrastructure?**
 
@@ -43,7 +43,7 @@ Absolutely.
 
 Cattle will not supported in v2.x as Rancher has been re-architected to be based on Kubernetes. You can, however, expect majority of Cattle features you use will exist and function similarly on Kubernetes. We will develop migration tools in Rancher v2.1 to help you transform your existing Rancher Compose files into Kubernetes YAML files.
 
-<br>
+<br/>
 
 **Can I migrate existing Cattle workloads into Kubernetes?**
 
@@ -55,19 +55,19 @@ Yes. In the upcoming Rancher v2.1 release we will provide a tool to help transla
 
 Yes. You can manage Kubernetes storage, networking, and its vast ecosystem of add-ons.
 
-<br>
+<br/>
 
 **Are there changes to default roles available now or going forward? Will the Kubernetes alignment impact plans for roles/RBAC?**
 
 The default roles will be expanded to accommodate the new Rancher 2.x features, and will also take advantage of the Kubernetes RBAC (Role-Based Access Control) capabilities to give you more flexibility.
 
-<br>
+<br/>
 
 **Will there be any functions like network policies to separate a front-end container from a back-end container through some kind of firewall in v2.x?**
 
 Yes. You can do so by leveraging Kubernetes' network policies.
 
-<br>
+<br/>
 
 **What about the CLI? Will that work the same way with the same features?**
 
@@ -81,7 +81,7 @@ Starting with 2.0, the concept of an environment has now been changed to a Kuber
 
 Kubernetes RKE Templates is on our roadmap for 2.x. Please refer to our Release Notes and documentation for all the features that we currently support.
 
-<br>
+<br/>
 
 **Can you still add an existing host to an environment? (i.e. not provisioned directly from Rancher)**
 
@@ -93,7 +93,7 @@ Yes. We still provide you with the same way of executing our Rancher agents dire
 
 Due to the technical difficulty in transforming a Docker container into a pod running Kubernetes, upgrading will require users to "replay" those workloads from v1.x into new v2.x environments. We plan to ship with a tool in v2.1 to translate existing Rancher Compose files into Kubernetes YAML files.  You will then be able to deploy those workloads on the v2.x platform.
 
-<br>
+<br/>
 
 **Is it possible to upgrade from Rancher v1.x to v2.x without any disruption to Cattle and Kubernetes clusters?**
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md
index 73d1f6efe48..2b7c2e37b3a 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md
@@ -117,7 +117,7 @@ This reference contains variables that you can use in `questions.yml` nested und
 | 	max_length        | int     | false      | Max character length.|
 | 	min               | int     | false      |  Min integer length. |
 | 	max               | int     | false      |  Max integer length. |
-| 	options           | []string | false     |  Specify the options when the variable type is `enum`, for example: options:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
+| 	options           | []string | false     |  Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
 | 	valid_chars       | string   | false     |  Regular expression for input chars validation. |
 | 	invalid_chars     | string   | false     |  Regular expression for invalid input chars validation.|
 | 	subquestions      | []subquestion | false|  Add an array of subquestions.|
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
index ecf32661571..fed4dc7a211 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
@@ -61,8 +61,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
 
 | Configuration                              | Chart option                 | Description                                                                                                                                                 | Requires cert-manager |
 | ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
-| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
-| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template.                  | no                    |
+| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
+| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template.                  | no                    |
 
 ### C. Render the Rancher Helm Template
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
index 08e40ac80d1..0fe9734c28d 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
@@ -29,9 +29,9 @@ By default, we provide the steps of how to populate your private registry assumi
 
 For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry.
 
-A. Find the required assets for your Rancher version <br>
-B. Collect all the required images <br>
-C. Save the images to your workstation <br>
+A. Find the required assets for your Rancher version <br/>
+B. Collect all the required images <br/>
+C. Save the images to your workstation <br/>
 D. Populate the private registry
 
 ### Prerequisites
@@ -115,9 +115,9 @@ For Rancher servers that will provision Linux and Windows clusters, there are di
 
 The Windows images need to be collected and pushed from a Windows server workstation.
 
-A. Find the required assets for your Rancher version <br>
-B. Save the images to your Windows Server workstation <br>
-C. Prepare the Docker daemon <br>
+A. Find the required assets for your Rancher version <br/>
+B. Save the images to your Windows Server workstation <br/>
+C. Prepare the Docker daemon <br/>
 D. Populate the private registry
 
 {{% accordion label="Collecting and Populating Windows Images into the Private Registry"%}}
@@ -189,9 +189,9 @@ Move the images in the `rancher-windows-images.tar.gz` to your private registry
 
 The Linux images needs to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images.
 
-A. Find the required assets for your Rancher version <br>
-B. Collect all the required images <br>
-C. Save the images to your Linux workstation <br>
+A. Find the required assets for your Rancher version <br/>
+B. Collect all the required images <br/>
+C. Save the images to your Linux workstation <br/>
 D. Populate the private registry
 
 {{% accordion label="Collecting and Populating Linux Images into the Private Registry" %}}
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
index a003fdc2bbe..682484fc664 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -187,7 +187,7 @@ spec:
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
-1. Test that pod autoscaling works as intended.<br/></br>
+1. Test that pod autoscaling works as intended.<br/><br/>
   **To Test Autoscaling Using Resource Metrics:**
   {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
 Use your load testing tool to scale up to two pods based on CPU Usage.
diff --git a/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md b/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md
index e84fe21de1b..582498c1d19 100644
--- a/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md
+++ b/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md
@@ -29,11 +29,11 @@ helm repo update
 helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
 helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
 ```
-</br>
+<br/>
 For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
 ```
 --set image.repository $REGISTRY/rancher/backup-restore-operator
-``` 
+```
 
 ### 2. Restore from backup using a Restore custom resource
 
@@ -52,7 +52,7 @@ stringData:
 
 This secret can be created in any namespace, with the above example it will get created in the default namespace
 
-In the Restore custom resource, `prune` must be set to false. 
+In the Restore custom resource, `prune` must be set to false.
 
 Create a Restore custom resource like the example below:
 
@@ -76,18 +76,18 @@ spec:
       endpoint: s3.us-west-2.amazonaws.com
 ```
 
->**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:  
+>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:
 
-1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:   
+1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
     ```
     kubectl create secret generic encryptionconfig \
       --from-file=./encryption-provider-config.yaml \
       -n cattle-resources-system
     ```
-  
+
 1. Then apply the resource:
     ```
-    kubectl apply -f migrationResource.yaml 
+    kubectl apply -f migrationResource.yaml
     ```
 
 ### 3. Install cert-manager
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md
index deaaaac4fc5..f9696d32730 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md
@@ -20,9 +20,9 @@ If you encounter this issue, you can work around it by installing the initiator
 After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.
 
 >**Notes:**
->  
->- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
-></br>
+>
+>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.<br/>
+><br/>
 >
 >- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.
 
diff --git a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
index 0816641dd5a..5f4a16b0367 100644
--- a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -187,7 +187,7 @@ spec:
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
-1. Test that pod autoscaling works as intended.<br/></br>
+1. Test that pod autoscaling works as intended.<br/><br/>
   **To Test Autoscaling Using Resource Metrics:**
   {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
 Use your load testing tool to scale up to two pods based on CPU Usage.
diff --git a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
index 30b19cdbc66..fcd70f138e8 100644
--- a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
+++ b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
 - Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
 `kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
 
-- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet. 
-    
+- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
+
 - We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
 
-1. The PushProx Client establishes an outbound connection with the PushProx Proxy.    
+1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
 1. The client then polls the proxy for scrape requests that have come into the proxy.
 1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
 1. The client scrapes the internal component.
 1. The internal component responds by pushing metrics back to the proxy.
-    
 
-<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
+
+<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>
 
 ![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)
 
@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
 ### Alerts Forwarded by alertingDrivers
 
 When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
-    
+
 ### Routing Alerts to Receivers
 
 Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
diff --git a/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md b/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md
index 1b129ee97f0..c1502c71664 100644
--- a/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md
+++ b/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md
@@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
 
 1. Click **☰ > Continuous Delivery**.
 
-1. Select your namespace at the top of the menu, noting the following: 
-    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. 
-    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. 
+1. Select your namespace at the top of the menu, noting the following:
+    - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
+    - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
     - You can then manage clusters by clicking on **Clusters** on the left navigation bar.
 
-1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. 
+1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
 
 1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
 
@@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts
 # Troubleshooting
 
 ---
-* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. 
+* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place.
 
-* **Temporary Workaround:** </br>
+* **Temporary Workaround:** <br/>
 By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
 
 ---
diff --git a/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md b/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md
index a9f79c0bddd..d9ce2fe6437 100644
--- a/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md
+++ b/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md
@@ -17,30 +17,30 @@ For users looking to use another container runtime, Rancher has the edge-focused
 
 ### FAQ
 
-<br>
+<br/>
 
-Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?  
+Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
 
 The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details.
 
-<br> 
+<br/>
 
-Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?   
+Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
 
 A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed.
 
 For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
 
-<br>
+<br/>
 
-Q: What are my other options if I don’t want to depend on the Dockershim? 
+Q: What are my other options if I don’t want to depend on the Dockershim?
 
 A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
 
-<br>
+<br/>
 
-Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?  
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
 
-A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl. 
+A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl.
 
-<br>
+<br/>
diff --git a/versioned_docs/version-2.6/v2.6/en/faq/faq.md b/versioned_docs/version-2.6/v2.6/en/faq/faq.md
index 4fc0889d102..92b3894af2a 100644
--- a/versioned_docs/version-2.6/v2.6/en/faq/faq.md
+++ b/versioned_docs/version-2.6/v2.6/en/faq/faq.md
@@ -7,25 +7,25 @@ This FAQ is a work in progress designed to answers the questions our users most
 
 See [Technical FAQ]({{<baseurl>}}/rancher/v2.6/en/faq/technical/), for frequently asked technical questions.
 
-<br>
+<br/>
 
 **Does Rancher v2.x support Docker Swarm and Mesos as environment types?**
 
 When creating an environment in Rancher v2.x, Swarm and Mesos will no longer be standard options you can select. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 or so are running Swarm.
 
-<br>
+<br/>
 
 **Is it possible to manage Azure Kubernetes Services with Rancher v2.x?**
 
 Yes.
 
-<br>
+<br/>
 
 **Does Rancher support Windows?**
 
 As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/)
 
-<br>
+<br/>
 
 **Does Rancher support Istio?**
 
@@ -33,37 +33,37 @@ As of Rancher 2.3.0, we support [Istio.]({{<baseurl>}}/rancher/v2.6/en/istio/)
 
 Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)
 
-<br>
+<br/>
 
 **Will Rancher v2.x support Hashicorp's Vault for storing secrets?**
 
-Secrets management is on our roadmap but we haven't assigned it to a specific release yet. 
+Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
 
-<br>
+<br/>
 
 **Does Rancher v2.x support RKT containers as well?**
 
 At this time, we only support Docker.
 
-<br>
+<br/>
 
 **Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and registered Kubernetes?**
 
 Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave.  Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported.
 
-<br>
+<br/>
 
 **Are you planning on supporting Traefik for existing setups?**
 
 We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches.
 
-<br>
+<br/>
 
 **Can I import OpenShift Kubernetes clusters into v2.x?**
 
 Our goal is to run any upstream Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet.
 
-<br>
+<br/>
 
 **Are you going to integrate Longhorn?**
 
diff --git a/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md b/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md
index ea4bbde4872..a7104cc5dfc 100644
--- a/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md
+++ b/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md
@@ -46,7 +46,7 @@ CNI network providers using this network model include Calico and Cilium. Cilium
 
 ### RKE Kubernetes clusters
 
-Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave. 
+Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave.
 
 You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
 
@@ -95,7 +95,7 @@ For more information, see the following pages:
 
 ### RKE2 Kubernetes clusters
 
-Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium. 
+Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium.
 
 You can choose your CNI network provider when you create new Kubernetes clusters from Rancher.
 
@@ -111,7 +111,7 @@ Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if
 
 >**Important:** In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. <b>Note that this issue is resolved in v2.6.4.<b>
 >
->- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`. 
+>- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
 >
 >- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`.
 
@@ -126,12 +126,12 @@ For more information, see the following pages:
 
 ![Cilium Logo]({{<baseurl>}}/img/rancher/cilium-logo.png)
 
-Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured. 
+Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured.
 
 Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements).
 
 ##### Ingress Routing Across Nodes in Cilium
-<br>
+<br/>
 By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`.
 
 After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows:
@@ -143,7 +143,7 @@ metadata:
   name: hn-nodes
   namespace: default
 spec:
-  endpointSelector: {} 
+  endpointSelector: {}
   ingress:
     - fromEntities:
       - remote-node
diff --git a/versioned_docs/version-2.6/v2.6/en/faq/security/security.md b/versioned_docs/version-2.6/v2.6/en/faq/security/security.md
index 55eb76ee087..6759f6d2946 100644
--- a/versioned_docs/version-2.6/v2.6/en/faq/security/security.md
+++ b/versioned_docs/version-2.6/v2.6/en/faq/security/security.md
@@ -8,7 +8,7 @@ weight: 8007
 
 The Hardening Guide is now located in the main [Security]({{<baseurl>}}/rancher/v2.6/en/security/) section.
 
-<br>
+<br/>
 
 **What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
 
diff --git a/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md b/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md
index b4376f81ef7..3e8555a0f8c 100644
--- a/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md
+++ b/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md
@@ -68,7 +68,7 @@ Before you create your own custom catalog, you should have a basic understanding
 
 	<figcaption>Rancher Chart with <code>questions.yml</code> (top) vs. Helm Chart without (bottom)</figcaption>
 
-	![questions.yml]({{<baseurl>}}/img/rancher/rancher-app-2.6.png) 
+	![questions.yml]({{<baseurl>}}/img/rancher/rancher-app-2.6.png)
 	![values.yaml]({{<baseurl>}}/img/rancher/helm-app-2.6.png)
 
 
@@ -118,7 +118,7 @@ This reference contains variables that you can use in `questions.yml` nested und
 | 	max_length        | int     | false      | Max character length.|
 | 	min               | int     | false      |  Min integer length. |
 | 	max               | int     | false      |  Max integer length. |
-| 	options           | []string | false     |  Specify the options when the variable type is `enum`, for example: options:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
+| 	options           | []string | false     |  Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "LoadBalancer"|
 | 	valid_chars       | string   | false     |  Regular expression for input chars validation. |
 | 	invalid_chars     | string   | false     |  Regular expression for invalid input chars validation.|
 | 	subquestions      | []subquestion | false|  Add an array of subquestions.|
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index a739fd07987..631cc6c4278 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -9,7 +9,7 @@ This section is about how to deploy Rancher for your air gapped environment in a
 
 When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option.
 
-# Docker Instructions 
+# Docker Instructions
 
 If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](./docker-install-commands)
 
@@ -56,8 +56,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
 
 | Configuration                              | Chart option                 | Description                                                                                                                                                 | Requires cert-manager |
 | ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
-| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
-| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template.                  | no                    |
+| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes                   |
+| Certificates from Files                    | `ingress.tls.source=secret`  | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template.                  | no                    |
 
 # Helm Chart Options for Air Gap Installations
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md b/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md
index e4c3490c4b2..610eb3233e8 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md
@@ -17,28 +17,28 @@ For users looking to use another container runtime, Rancher has the edge-focused
 
 ### FAQ
 
-<br>
+<br/>
 
-Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?  
+Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim?
 
 A The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on a version of Rancher that supports RKE 1.21. See our support matrix for details.
 
-<br> 
+<br/>
 
-Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?   
+Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim?
 
 A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and it is not deprecated until a later release. For information on the timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to 1.21 as you would normally.
 
-<br>
+<br/>
 
-Q: What are my other options if I don’t want to depend on the Dockershim? 
+Q: What are my other options if I don’t want to depend on the Dockershim?
 
 A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this.
 
-<br>
+<br/>
 
-Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?  
+Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
 
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path. 
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
 
-<br>
+<br/>
diff --git a/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
index 30b19cdbc66..fcd70f138e8 100644
--- a/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
+++ b/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
 - Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
 `kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.
 
-- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet. 
-    
+- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
+
 - We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:
 
-1. The PushProx Client establishes an outbound connection with the PushProx Proxy.    
+1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
 1. The client then polls the proxy for scrape requests that have come into the proxy.
 1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
 1. The client scrapes the internal component.
 1. The internal component responds by pushing metrics back to the proxy.
-    
 
-<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
+
+<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>
 
 ![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)
 
@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
 ### Alerts Forwarded by alertingDrivers
 
 When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
-    
+
 ### Routing Alerts to Receivers
 
 Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.
diff --git a/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md b/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md
index 86b10606e47..333d4aff51f 100644
--- a/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md
+++ b/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md
@@ -130,7 +130,7 @@ PLUGIN_MIRROR           | Docker daemon registry mirror
 PLUGIN_INSECURE         | Docker daemon allows insecure registries
 PLUGIN_BUILD_ARGS       | Docker build args, a comma separated list
 
-<br>
+<br/>
 
 ```yaml
 # This example shows an environment variable being used
@@ -502,7 +502,7 @@ If you need to use security-sensitive information in your pipeline scripts (like
 
 ### Prerequisite
 Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run.
-<br>
+<br/>
 
 >**Note:** Secret injection is disabled on [pull request events](#triggers-and-trigger-rules).
 
@@ -556,7 +556,7 @@ Variable Name           | Description
 
 # Global Pipeline Execution Settings
 
-After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. 
+After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher.
 
 ### Changing Pipeline Settings
 
@@ -622,7 +622,7 @@ stages:
 
 >**Note:** Rancher sets default compute resources for pipeline steps except for `Build and Publish Images` and `Run Script` steps. You can override the default value by specifying compute resources in the same way.
 
-### Custom CA  
+### Custom CA
 
 If you want to use a version control provider with a certificate from a custom/internal CA root, the CA root certificates need to be added as part of the version control provider configuration in order for the pipeline build pods to succeed.
 

From 7e4e72da5fa0799b37c3a6f9a28bf67314c6fbcf Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 16:58:32 -0700
Subject: [PATCH 5/9] Enclose in backticks so <&tag> aren't processed as HTML
 tags

---
 .../load-balancers-and-ingress/load-balancers/load-balancers.md | 2 +-
 .../load-balancers-and-ingress/load-balancers/load-balancers.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md b/docs/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
index 33046bd2639..097dfc1232c 100644
--- a/docs/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
+++ b/docs/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
@@ -59,7 +59,7 @@ Some cloud-managed layer-7 load balancers (such as the ALB ingress controller on
 Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress Controller, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. Nginx Ingress Controller exposes the external IP of all nodes that run the Nginx Ingress Controller. You can do either of the following:
 
 1.	Configure your own DNS to map (via A records) your domain name to the IP addresses exposes by the Layer-7 load balancer.
-2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name <ingressname>.<namespace>.a.b.c.d.xip.io.
+2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say `a.b.c.d`, and generate a host name `<ingressname>.<namespace>.a.b.c.d.xip.io`.
 
 The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate.
 
diff --git a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
index 9ee09220401..0e594f7efd9 100644
--- a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
+++ b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/load-balancers.md
@@ -55,7 +55,7 @@ Some cloud-managed layer-7 load balancers (such as the ALB ingress controller on
 Other layer-7 load balancers, such as the Google Load Balancer or Nginx Ingress Controller, directly expose one or more IP addresses. Google Load Balancer provides a single routable IP address. Nginx Ingress Controller exposes the external IP of all nodes that run the Nginx Ingress Controller. You can do either of the following:
 
 1.	Configure your own DNS to map (via A records) your domain name to the IP addresses exposes by the Layer-7 load balancer.
-2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say a.b.c.d, and generate a host name <ingressname>.<namespace>.a.b.c.d.xip.io.
+2.	Ask Rancher to generate an xip.io host name for your ingress rule. Rancher will take one of your exposed IPs, say `a.b.c.d`, and generate a host name `<ingressname>.<namespace>.a.b.c.d.xip.io`.
 
 The benefit of using xip.io is that you obtain a working entrypoint URL immediately after you create the ingress rule. Setting up your own domain name, on the other hand, requires you to configure DNS servers and wait for DNS to propagate.
 

From 23d774439fb0c6c4768d8071b91a2acf3df54144 Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 17:11:15 -0700
Subject: [PATCH 6/9] Enclose in backticks so <&tag> aren't processed as HTML
 tags - 2

---
 .../rke-1.6-benchmark-2.6.md                  | 40 +++++------
 .../rke2-1.6-benchmark-2.6.md                 | 44 ++++++------
 .../benchmark-2.3.5/benchmark-2.3.5.md        | 70 +++++++++----------
 .../benchmark-2.4/benchmark-2.4.md            | 70 +++++++++----------
 .../1.5-benchmark-2.5/1.5-benchmark-2.5.md    | 30 ++++----
 .../1.6-benchmark-2.5/1.6-benchmark-2.5.md    | 60 ++++++++--------
 .../rke-1.6-benchmark-2.6.md                  | 40 +++++------
 .../rke2-1.6-benchmark-2.6.md                 | 44 ++++++------
 8 files changed, 199 insertions(+), 199 deletions(-)

diff --git a/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md b/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
index 2f4f1d724fa..f6bd2a79028 100644
--- a/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
+++ b/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
@@ -677,8 +677,8 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and setup the TLS connection between
 the apiserver and kubelets. Then, edit the API server pod specification file
 /etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
---kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
---kubelet-certificate-authority=<ca-string>
+`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
+`--kubelet-certificate-authority=<ca-string>`
 
 **Audit:**
 
@@ -1288,7 +1288,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the --service-account-key-file parameter
 to the public key file for service accounts:
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 
 **Audit:**
 
@@ -1317,8 +1317,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate and key file parameters.
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 
 **Audit:**
 
@@ -1347,8 +1347,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the TLS certificate and private key file parameters.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 
 **Audit:**
 
@@ -1377,7 +1377,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the client certificate authority file.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 
 **Audit:**
 
@@ -1406,7 +1406,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate authority file parameter.
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 
 **Audit:**
 
@@ -1626,7 +1626,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --service-account-private-key-file parameter
 to the private key file for service accounts.
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 
 **Audit:**
 
@@ -1654,7 +1654,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
 **Remediation:**
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --root-ca-file parameter to the certificate bundle file`.
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 
 **Audit:**
 
@@ -1779,8 +1779,8 @@ root 121587 121567 0 12:27 ? 00:00:12 kube-scheduler --kubeconfig=/etc/kubernete
 Follow the etcd service documentation and configure TLS encryption.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
 on the master node and set the below parameters.
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 
 **Audit:**
 
@@ -1866,8 +1866,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
 for your etcd cluster.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameters.
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 
 **Audit:**
 
@@ -1954,7 +1954,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
 etcd service.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameter.
---trusted-ca-file=</path/to/ca-file>
+`--trusted-ca-file=</path/to/ca-file>`
 
 **Audit:**
 
@@ -2145,7 +2145,7 @@ root:root
 
 **Remediation:**
 Run the following command to modify the file permissions of the
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 
 **Audit Script:** `check_cafile_permissions.sh`
 
@@ -2305,7 +2305,7 @@ the location of the client CA file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameter in KUBELET_AUTHZ_ARGS variable.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2526,8 +2526,8 @@ to the location of the corresponding private key file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
diff --git a/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md b/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
index 76297744ffa..f97cec92319 100644
--- a/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
+++ b/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
@@ -869,8 +869,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and setup the TLS connection between
 the apiserver and kubelets. Then, edit the API server pod specification file
 /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml on the master node and set the
---kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
---kubelet-certificate-authority=<ca-string>
+`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
+`--kubelet-certificate-authority=<ca-string>`
 
 **Audit:**
 
@@ -1468,7 +1468,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the --service-account-key-file parameter
 to the public key file for service accounts:
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 
 **Audit:**
 
@@ -1497,8 +1497,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate and key file parameters.
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 
 **Audit:**
 
@@ -1527,8 +1527,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the TLS certificate and private key file parameters.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 
 **Audit:**
 
@@ -1557,7 +1557,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the client certificate authority file.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 
 **Audit:**
 
@@ -1586,7 +1586,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate authority file parameter.
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 
 **Audit:**
 
@@ -1787,7 +1787,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
 Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
 on the master node and set the --service-account-private-key-file parameter
 to the private key file for service accounts.
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 
 **Audit:**
 
@@ -1815,7 +1815,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
 **Remediation:**
 Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
 on the master node and set the --root-ca-file parameter to the certificate bundle file`.
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 
 **Audit:**
 
@@ -1938,8 +1938,8 @@ root 5533 5414 0 14:58 ? 00:00:02 kube-scheduler --permit-port-sharing=true --ad
 Follow the etcd service documentation and configure TLS encryption.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
 on the master node and set the below parameters.
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 
 ### 2.2 Ensure that the --client-cert-auth argument is set to true (Automated)
 
@@ -1989,8 +1989,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
 for your etcd cluster.
 Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
 master node and set the below parameters.
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 
 ### 2.5 Ensure that the --peer-client-cert-auth argument is set to true (Automated)
 
@@ -2041,7 +2041,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
 etcd service.
 Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
 master node and set the below parameter.
---trusted-ca-file=</path/to/ca-file>
+`--trusted-ca-file=</path/to/ca-file>`
 
 **Audit:**
 
@@ -2258,7 +2258,7 @@ root:root
 
 **Remediation:**
 Run the following command to modify the file permissions of the
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 
 **Audit:**
 
@@ -2438,7 +2438,7 @@ the location of the client CA file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameter in KUBELET_AUTHZ_ARGS variable.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2693,8 +2693,8 @@ to the location of the corresponding private key file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2929,7 +2929,7 @@ echo "true"
 **Audit Execution:**
 
 ```bash
-./check_for_default_sa.sh 
+./check_for_default_sa.sh
 ```
 
 **Expected Result**:
@@ -3228,7 +3228,7 @@ echo "true"
 **Audit Execution:**
 
 ```bash
-./check_for_rke2_network_policies.sh 
+./check_for_rke2_network_policies.sh
 ```
 
 **Expected Result**:
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.5/benchmark-2.3.5/benchmark-2.3.5.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.5/benchmark-2.3.5/benchmark-2.3.5.md
index 3fbb7f27f16..f6331e1176e 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.5/benchmark-2.3.5/benchmark-2.3.5.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.5/benchmark-2.3.5/benchmark-2.3.5.md
@@ -39,7 +39,7 @@ When performing the tests, you will need access to the Docker command line on th
 
 ---
 ## 1 Master Node Security Configuration
-### 1.1 Master Node Configuration Files 
+### 1.1 Master Node Configuration Files
 
 #### 1.1.1 Ensure that the API server pod specification file permissions are set to `644` or more restrictive (Scored)
 
@@ -155,7 +155,7 @@ Run the below command (based on the etcd data directory found above).
 For example,
 ``` bash
 chown etcd:etcd /var/lib/etcd
-``` 
+```
 
 **Audit Script:** 1.1.12.sh
 
@@ -189,7 +189,7 @@ docker inspect etcd | jq -r '.[].HostConfig.Binds[]' | grep "${test_dir}" | cut
 RKE does not store the kubernetes default kubeconfig credentials file on the nodes. It’s presented to user where RKE is run.
 We recommend that this `kube_config_cluster.yml` file be kept in secure store.
 
-#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored) 
+#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
 
 **Result:** Not Applicable
 
@@ -249,7 +249,7 @@ stat -c %U:%G /etc/kubernetes/ssl
 'root:root' is present
 ```
 
-#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored) 
+#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
 
 **Result:** PASS
 
@@ -732,7 +732,7 @@ on the master node and set the below parameter.
 '0' is equal to '0'
 ```
 
-#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored) 
+#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
 
 **Result:** PASS
 
@@ -938,7 +938,7 @@ on the master node and set the `--service-account-key-file` parameter
 to the public key file for service accounts:
 
 ``` bash
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 ```
 
 **Audit:**
@@ -953,7 +953,7 @@ to the public key file for service accounts:
 '--service-account-key-file' is present
 ```
 
-#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored) 
+#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
 
 **Result:** PASS
 
@@ -963,8 +963,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the **etcd** certificate and **key** file parameters.
 
 ``` bash
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 ```
 
 **Audit:**
@@ -989,8 +989,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the TLS certificate and private key file parameters.
 
 ``` bash
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 ```
 
 **Audit:**
@@ -1015,7 +1015,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the client certificate authority file.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 **Audit:**
@@ -1040,7 +1040,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the etcd certificate authority file parameter.
 
 ``` bash
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 ```
 
 **Audit:**
@@ -1202,7 +1202,7 @@ on the master node and set the `--service-account-private-key-file` parameter
 to the private key file for service accounts.
 
 ``` bash
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 ```
 
 **Audit:**
@@ -1226,7 +1226,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
 on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
 
 ``` bash
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 ```
 
 **Audit:**
@@ -1311,7 +1311,7 @@ on the master node and set the below parameter.
 'false' is equal to 'false'
 ```
 
-#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored) 
+#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
 
 **Result:** PASS
 
@@ -1344,8 +1344,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
 on the master node and set the below parameters.
 
 ``` bash
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 ```
 
 **Audit:**
@@ -1418,8 +1418,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
 master node and set the below parameters.
 
 ``` bash
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 ```
 
 **Audit:**
@@ -1485,7 +1485,7 @@ node and either remove the `--peer-auto-tls` parameter or set it to `false`.
 ## 3 Control Plane Configuration
 ### 3.2 Logging
 
-#### 3.2.1 Ensure that a minimal audit policy is created (Scored) 
+#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
 
 **Result:** PASS
 
@@ -1546,7 +1546,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected result**:
@@ -1561,7 +1561,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 
 **Remediation:**
 Run the below command (based on the file location on your system) on the each worker node.
-For example, 
+For example,
 
 ``` bash
 chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
@@ -1570,7 +1570,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected result**:
@@ -1594,7 +1594,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected result**:
@@ -1618,7 +1618,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected result**:
@@ -1635,7 +1635,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 Run the following command to modify the file permissions of the
 
 ``` bash
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 ```
 
 **Audit:**
@@ -1664,7 +1664,7 @@ chown root:root <filename>
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
 ```
 
 **Expected result**:
@@ -1703,7 +1703,7 @@ set the below parameter in `KUBELET_SYSTEM_PODS_ARGS` variable.
 ``` bash
 --anonymous-auth=false
 ```
- 
+
 Based on your system, restart the kubelet service. For example:
 
 ``` bash
@@ -1780,7 +1780,7 @@ If using command line arguments, edit the kubelet service file
 set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 Based on your system, restart the kubelet service. For example:
@@ -1926,7 +1926,7 @@ systemctl restart kubelet.service
 'true' is equal to 'true'
 ```
 
-#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored) 
+#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
 
 **Result:** PASS
 
@@ -1938,7 +1938,7 @@ remove the `--make-iptables-util-chains` argument from the
 `KUBELET_SYSTEM_PODS_ARGS` variable.
 Based on your system, restart the kubelet service. For example:
 
-```bash 
+```bash
 systemctl daemon-reload
 systemctl restart kubelet.service
 ```
@@ -2091,7 +2091,7 @@ exit 0
 **Audit Execution:**
 
 ```
-./5.1.5.sh 
+./5.1.5.sh
 ```
 
 **Expected result**:
@@ -2218,7 +2218,7 @@ echo "pass"
 **Audit Execution:**
 
 ```
-./5.3.2.sh 
+./5.3.2.sh
 ```
 
 **Expected result**:
@@ -2258,7 +2258,7 @@ echo "--count=${default_resources}"
 **Audit Execution:**
 
 ```
-./5.6.4.sh 
+./5.6.4.sh
 ```
 
 **Expected result**:
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.4/benchmark-2.4/benchmark-2.4.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.4/benchmark-2.4/benchmark-2.4.md
index f1e0767ab99..6c9debdaf14 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.4/benchmark-2.4/benchmark-2.4.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.4/benchmark-2.4/benchmark-2.4.md
@@ -39,7 +39,7 @@ When performing the tests, you will need access to the Docker command line on th
 
 ---
 ## 1 Master Node Security Configuration
-### 1.1 Master Node Configuration Files 
+### 1.1 Master Node Configuration Files
 
 #### 1.1.1 Ensure that the API server pod specification file permissions are set to `644` or more restrictive (Scored)
 
@@ -155,7 +155,7 @@ Run the below command (based on the etcd data directory found above).
 For example,
 ``` bash
 chown etcd:etcd /var/lib/etcd
-``` 
+```
 
 **Audit Script:** 1.1.12.sh
 
@@ -189,7 +189,7 @@ docker inspect etcd | jq -r '.[].HostConfig.Binds[]' | grep "${test_dir}" | cut
 RKE does not store the kubernetes default kubeconfig credentials file on the nodes. It’s presented to user where RKE is run.
 We recommend that this `kube_config_cluster.yml` file be kept in secure store.
 
-#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored) 
+#### 1.1.14 Ensure that the admin.conf file ownership is set to `root:root` (Scored)
 
 **Result:** Not Applicable
 
@@ -249,7 +249,7 @@ stat -c %U:%G /etc/kubernetes/ssl
 'root:root' is present
 ```
 
-#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored) 
+#### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to `644` or more restrictive (Scored)
 
 **Result:** PASS
 
@@ -732,7 +732,7 @@ on the master node and set the below parameter.
 '0' is equal to '0'
 ```
 
-#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored) 
+#### 1.2.20 Ensure that the `--secure-port` argument is not set to `0` (Scored)
 
 **Result:** PASS
 
@@ -938,7 +938,7 @@ on the master node and set the `--service-account-key-file` parameter
 to the public key file for service accounts:
 
 ``` bash
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 ```
 
 **Audit:**
@@ -953,7 +953,7 @@ to the public key file for service accounts:
 '--service-account-key-file' is present
 ```
 
-#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored) 
+#### 1.2.29 Ensure that the `--etcd-certfile` and `--etcd-keyfile` arguments are set as appropriate (Scored)
 
 **Result:** PASS
 
@@ -963,8 +963,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the **etcd** certificate and **key** file parameters.
 
 ``` bash
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 ```
 
 **Audit:**
@@ -989,8 +989,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the TLS certificate and private key file parameters.
 
 ``` bash
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 ```
 
 **Audit:**
@@ -1015,7 +1015,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the client certificate authority file.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 **Audit:**
@@ -1040,7 +1040,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the etcd certificate authority file parameter.
 
 ``` bash
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 ```
 
 **Audit:**
@@ -1202,7 +1202,7 @@ on the master node and set the `--service-account-private-key-file` parameter
 to the private key file for service accounts.
 
 ``` bash
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 ```
 
 **Audit:**
@@ -1226,7 +1226,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
 on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
 
 ``` bash
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 ```
 
 **Audit:**
@@ -1311,7 +1311,7 @@ on the master node and set the below parameter.
 'false' is equal to 'false'
 ```
 
-#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored) 
+#### 1.4.2 Ensure that the `--bind-address` argument is set to `127.0.0.1` (Scored)
 
 **Result:** PASS
 
@@ -1344,8 +1344,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
 on the master node and set the below parameters.
 
 ``` bash
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 ```
 
 **Audit:**
@@ -1418,8 +1418,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
 master node and set the below parameters.
 
 ``` bash
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 ```
 
 **Audit:**
@@ -1485,7 +1485,7 @@ node and either remove the `--peer-auto-tls` parameter or set it to `false`.
 ## 3 Control Plane Configuration
 ### 3.2 Logging
 
-#### 3.2.1 Ensure that a minimal audit policy is created (Scored) 
+#### 3.2.1 Ensure that a minimal audit policy is created (Scored)
 
 **Result:** PASS
 
@@ -1546,7 +1546,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected result**:
@@ -1561,7 +1561,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 
 **Remediation:**
 Run the below command (based on the file location on your system) on the each worker node.
-For example, 
+For example,
 
 ``` bash
 chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
@@ -1570,7 +1570,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected result**:
@@ -1594,7 +1594,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected result**:
@@ -1618,7 +1618,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected result**:
@@ -1635,7 +1635,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 Run the following command to modify the file permissions of the
 
 ``` bash
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 ```
 
 **Audit:**
@@ -1664,7 +1664,7 @@ chown root:root <filename>
 **Audit:**
 
 ```
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kube-ca.pem; then stat -c %U:%G /etc/kubernetes/ssl/kube-ca.pem; fi'
 ```
 
 **Expected result**:
@@ -1703,7 +1703,7 @@ set the below parameter in `KUBELET_SYSTEM_PODS_ARGS` variable.
 ``` bash
 --anonymous-auth=false
 ```
- 
+
 Based on your system, restart the kubelet service. For example:
 
 ``` bash
@@ -1780,7 +1780,7 @@ If using command line arguments, edit the kubelet service file
 set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 Based on your system, restart the kubelet service. For example:
@@ -1926,7 +1926,7 @@ systemctl restart kubelet.service
 'true' is equal to 'true'
 ```
 
-#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored) 
+#### 4.2.7 Ensure that the `--make-iptables-util-chains` argument is set to `true` (Scored)
 
 **Result:** PASS
 
@@ -1938,7 +1938,7 @@ remove the `--make-iptables-util-chains` argument from the
 `KUBELET_SYSTEM_PODS_ARGS` variable.
 Based on your system, restart the kubelet service. For example:
 
-```bash 
+```bash
 systemctl daemon-reload
 systemctl restart kubelet.service
 ```
@@ -2091,7 +2091,7 @@ exit 0
 **Audit Execution:**
 
 ```
-./5.1.5.sh 
+./5.1.5.sh
 ```
 
 **Expected result**:
@@ -2218,7 +2218,7 @@ echo "pass"
 **Audit Execution:**
 
 ```
-./5.3.2.sh 
+./5.3.2.sh
 ```
 
 **Expected result**:
@@ -2258,7 +2258,7 @@ echo "--count=${default_resources}"
 **Audit Execution:**
 
 ```
-./5.6.4.sh 
+./5.6.4.sh
 ```
 
 **Expected result**:
diff --git a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/1.5-benchmark-2.5.md b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/1.5-benchmark-2.5.md
index 4fed8f40550..07859da7ca8 100644
--- a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/1.5-benchmark-2.5.md
+++ b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.5-benchmark-2.5/1.5-benchmark-2.5.md
@@ -937,7 +937,7 @@ on the master node and set the `--service-account-key-file` parameter
 to the public key file for service accounts:
 
 ``` bash
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 ```
 
 **Audit:**
@@ -962,8 +962,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the **etcd** certificate and **key** file parameters.
 
 ``` bash
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 ```
 
 **Audit:**
@@ -988,8 +988,8 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the TLS certificate and private key file parameters.
 
 ``` bash
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 ```
 
 **Audit:**
@@ -1014,7 +1014,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the client certificate authority file.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 **Audit:**
@@ -1039,7 +1039,7 @@ Then, edit the API server pod specification file `/etc/kubernetes/manifests/kube
 on the master node and set the etcd certificate authority file parameter.
 
 ``` bash
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 ```
 
 **Audit:**
@@ -1201,7 +1201,7 @@ on the master node and set the `--service-account-private-key-file` parameter
 to the private key file for service accounts.
 
 ``` bash
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 ```
 
 **Audit:**
@@ -1225,7 +1225,7 @@ Edit the Controller Manager pod specification file `/etc/kubernetes/manifests/ku
 on the master node and set the `--root-ca-file` parameter to the certificate bundle file`.
 
 ``` bash
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 ```
 
 **Audit:**
@@ -1343,8 +1343,8 @@ Then, edit the etcd pod specification file `/etc/kubernetes/manifests/etcd.yaml`
 on the master node and set the below parameters.
 
 ``` bash
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 ```
 
 **Audit:**
@@ -1417,8 +1417,8 @@ for your etcd cluster. Then, edit the etcd pod specification file `/etc/kubernet
 master node and set the below parameters.
 
 ``` bash
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 ```
 
 **Audit:**
@@ -1634,7 +1634,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 Run the following command to modify the file permissions of the
 
 ``` bash
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 ```
 
 **Audit:**
@@ -1779,7 +1779,7 @@ If using command line arguments, edit the kubelet service file
 set the below parameter in `KUBELET_AUTHZ_ARGS` variable.
 
 ``` bash
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 ```
 
 Based on your system, restart the kubelet service. For example:
diff --git a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
index e0dc1e45c5d..f435c8471fa 100644
--- a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
+++ b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
@@ -173,7 +173,7 @@ exit
 true
 
 ```
-### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive (Automated) 
+### 1.1.20 Ensure that the Kubernetes PKI certificate file permissions are set to 644 or more restrictive (Automated)
 
 **Result:** pass
 
@@ -766,8 +766,8 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Follow the Kubernetes documentation and setup the TLS connection between
 the apiserver and kubelets. Then, edit the API server pod specification file
 /etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
---kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
---kubelet-certificate-authority=<ca-string>
+`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
+`--kubelet-certificate-authority=<ca-string>`
 
 
 **Audit:**
@@ -1379,7 +1379,7 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the --service-account-key-file parameter
 to the public key file for service accounts:
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 
 
 **Audit:**
@@ -1408,8 +1408,8 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate and key file parameters.
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 
 
 **Audit:**
@@ -1438,8 +1438,8 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the TLS certificate and private key file parameters.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 
 
 **Audit:**
@@ -1468,7 +1468,7 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the client certificate authority file.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 
 
 **Audit:**
@@ -1497,7 +1497,7 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate authority file parameter.
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 
 
 **Audit:**
@@ -1717,7 +1717,7 @@ root        4788    4773  4 16:16 ?        00:00:09 kube-controller-manager --co
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --service-account-private-key-file parameter
 to the private key file for service accounts.
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 
 
 **Audit:**
@@ -1745,7 +1745,7 @@ root        4788    4773  4 16:16 ?        00:00:09 kube-controller-manager --co
 **Remediation:**
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --root-ca-file parameter to the certificate bundle file`.
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 
 
 **Audit:**
@@ -1877,8 +1877,8 @@ root        4947    4930  1 16:16 ?        00:00:02 kube-scheduler --kubeconfig=
 Follow the etcd service documentation and configure TLS encryption.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
 on the master node and set the below parameters.
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 
 
 **Audit:**
@@ -1973,8 +1973,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
 for your etcd cluster.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameters.
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 
 
 **Audit:**
@@ -2070,7 +2070,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
 etcd service.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameter.
---trusted-ca-file=</path/to/ca-file>
+`--trusted-ca-file=</path/to/ca-file>`
 
 
 **Audit:**
@@ -2167,7 +2167,7 @@ All configuration is passed in as arguments at container run time.
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c permissions=%a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi' 
+/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c permissions=%a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
 ```
 
 
@@ -2183,7 +2183,7 @@ All configuration is passed in as arguments at container run time.
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi' 
+/bin/sh -c 'if test -e /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; then stat -c %U:%G /etc/systemd/system/kubelet.service.d/10-kubeadm.conf; fi'
 ```
 
 
@@ -2200,7 +2200,7 @@ chmod 644 $proykubeconfig
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %a /node/etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected Result**:
@@ -2227,7 +2227,7 @@ For example, chown root:root /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; then stat -c %U:%G /etc/kubernetes/ssl/kubecfg-kube-proxy.yaml; fi'
 ```
 
 **Expected Result**:
@@ -2249,7 +2249,7 @@ chmod 644 /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c permissions=%a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c permissions=%a /etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected Result**:
@@ -2271,7 +2271,7 @@ chown root:root /etc/kubernetes/ssl/kubecfg-kube-node.yaml
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi' 
+/bin/sh -c 'if test -e /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; then stat -c %U:%G /node/etc/kubernetes/ssl/kubecfg-kube-node.yaml; fi'
 ```
 
 **Expected Result**:
@@ -2292,7 +2292,7 @@ root:root
 
 **Remediation:**
 Run the following command to modify the file permissions of the
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 
 
 **Audit:**
@@ -2361,7 +2361,7 @@ All configuration is passed in as arguments at container run time.
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c permissions=%a /var/lib/kubelet/config.yaml; fi' 
+/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c permissions=%a /var/lib/kubelet/config.yaml; fi'
 ```
 
 
@@ -2380,7 +2380,7 @@ All configuration is passed in as arguments at container run time.
 **Audit:**
 
 ```bash
-/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c %U:%G /var/lib/kubelet/config.yaml; fi' 
+/bin/sh -c 'if test -e /var/lib/kubelet/config.yaml; then stat -c %U:%G /var/lib/kubelet/config.yaml; fi'
 ```
 
 
@@ -2450,7 +2450,7 @@ the location of the client CA file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameter in KUBELET_AUTHZ_ARGS variable.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2602,7 +2602,7 @@ Clusters provisioned by RKE set the --hostname-override to avoid any hostname co
 **Audit:**
 
 ```bash
-/bin/ps -fC kubelet 
+/bin/ps -fC kubelet
 ```
 
 
@@ -2643,8 +2643,8 @@ to the location of the corresponding private key file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
diff --git a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
index 02b68e4a0e5..6dc2904182f 100644
--- a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
+++ b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
@@ -673,8 +673,8 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and setup the TLS connection between
 the apiserver and kubelets. Then, edit the API server pod specification file
 /etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
---kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
---kubelet-certificate-authority=<ca-string>
+`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
+`--kubelet-certificate-authority=<ca-string>`
 
 **Audit:**
 
@@ -1284,7 +1284,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the --service-account-key-file parameter
 to the public key file for service accounts:
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 
 **Audit:**
 
@@ -1313,8 +1313,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate and key file parameters.
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 
 **Audit:**
 
@@ -1343,8 +1343,8 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the TLS certificate and private key file parameters.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 
 **Audit:**
 
@@ -1373,7 +1373,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the client certificate authority file.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 
 **Audit:**
 
@@ -1402,7 +1402,7 @@ root 121142 121120 7 12:27 ? 00:06:28 kube-apiserver --audit-log-maxsize=100 --e
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate authority file parameter.
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 
 **Audit:**
 
@@ -1622,7 +1622,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --service-account-private-key-file parameter
 to the private key file for service accounts.
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 
 **Audit:**
 
@@ -1650,7 +1650,7 @@ root 121366 121346 1 12:27 ? 00:01:13 kube-controller-manager --cluster-cidr=10.
 **Remediation:**
 Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kube-controller-manager.yaml
 on the master node and set the --root-ca-file parameter to the certificate bundle file`.
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 
 **Audit:**
 
@@ -1775,8 +1775,8 @@ root 121587 121567 0 12:27 ? 00:00:12 kube-scheduler --kubeconfig=/etc/kubernete
 Follow the etcd service documentation and configure TLS encryption.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
 on the master node and set the below parameters.
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 
 **Audit:**
 
@@ -1862,8 +1862,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
 for your etcd cluster.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameters.
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 
 **Audit:**
 
@@ -1950,7 +1950,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
 etcd service.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
 master node and set the below parameter.
---trusted-ca-file=</path/to/ca-file>
+`--trusted-ca-file=</path/to/ca-file>`
 
 **Audit:**
 
@@ -2141,7 +2141,7 @@ root:root
 
 **Remediation:**
 Run the following command to modify the file permissions of the
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 
 **Audit Script:** `check_cafile_permissions.sh`
 
@@ -2301,7 +2301,7 @@ the location of the client CA file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameter in KUBELET_AUTHZ_ARGS variable.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2522,8 +2522,8 @@ to the location of the corresponding private key file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
diff --git a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
index 39c4c3409f3..8e4fc25bbfd 100644
--- a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
+++ b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
@@ -865,8 +865,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and setup the TLS connection between
 the apiserver and kubelets. Then, edit the API server pod specification file
 /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml on the master node and set the
---kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
---kubelet-certificate-authority=<ca-string>
+`--kubelet-certificate-authority` parameter to the path to the cert file for the certificate authority.
+`--kubelet-certificate-authority=<ca-string>`
 
 **Audit:**
 
@@ -1464,7 +1464,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the --service-account-key-file parameter
 to the public key file for service accounts:
---service-account-key-file=<filename>
+`--service-account-key-file=<filename>`
 
 **Audit:**
 
@@ -1493,8 +1493,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate and key file parameters.
---etcd-certfile=<path/to/client-certificate-file>
---etcd-keyfile=<path/to/client-key-file>
+`--etcd-certfile=<path/to/client-certificate-file>`
+`--etcd-keyfile=<path/to/client-key-file>`
 
 **Audit:**
 
@@ -1523,8 +1523,8 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the TLS certificate and private key file parameters.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 
 **Audit:**
 
@@ -1553,7 +1553,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection on the apiserver.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the client certificate authority file.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 
 **Audit:**
 
@@ -1582,7 +1582,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 Follow the Kubernetes documentation and set up the TLS connection between the apiserver and etcd.
 Then, edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
 on the master node and set the etcd certificate authority file parameter.
---etcd-cafile=<path/to/ca-file>
+`--etcd-cafile=<path/to/ca-file>`
 
 **Audit:**
 
@@ -1783,7 +1783,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
 Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
 on the master node and set the --service-account-private-key-file parameter
 to the private key file for service accounts.
---service-account-private-key-file=<filename>
+`--service-account-private-key-file=<filename>`
 
 **Audit:**
 
@@ -1811,7 +1811,7 @@ root 5522 5416 3 14:58 ? 00:00:16 kube-controller-manager --flex-volume-plugin-d
 **Remediation:**
 Edit the Controller Manager pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
 on the master node and set the --root-ca-file parameter to the certificate bundle file`.
---root-ca-file=<path/to/file>
+`--root-ca-file=<path/to/file>`
 
 **Audit:**
 
@@ -1934,8 +1934,8 @@ root 5533 5414 0 14:58 ? 00:00:02 kube-scheduler --permit-port-sharing=true --ad
 Follow the etcd service documentation and configure TLS encryption.
 Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml
 on the master node and set the below parameters.
---cert-file=</path/to/ca-file>
---key-file=</path/to/key-file>
+`--cert-file=</path/to/ca-file>`
+`--key-file=</path/to/key-file>`
 
 ### 2.2 Ensure that the --client-cert-auth argument is set to true (Automated)
 
@@ -1985,8 +1985,8 @@ Follow the etcd service documentation and configure peer TLS encryption as appro
 for your etcd cluster.
 Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
 master node and set the below parameters.
---peer-client-file=</path/to/peer-cert-file>
---peer-key-file=</path/to/peer-key-file>
+`--peer-client-file=</path/to/peer-cert-file>`
+`--peer-key-file=</path/to/peer-key-file>`
 
 ### 2.5 Ensure that the --peer-client-cert-auth argument is set to true (Automated)
 
@@ -2037,7 +2037,7 @@ Follow the etcd documentation and create a dedicated certificate authority setup
 etcd service.
 Then, edit the etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml on the
 master node and set the below parameter.
---trusted-ca-file=</path/to/ca-file>
+`--trusted-ca-file=</path/to/ca-file>`
 
 **Audit:**
 
@@ -2254,7 +2254,7 @@ root:root
 
 **Remediation:**
 Run the following command to modify the file permissions of the
---client-ca-file chmod 644 <filename>
+`--client-ca-file chmod 644 <filename>`
 
 **Audit:**
 
@@ -2434,7 +2434,7 @@ the location of the client CA file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameter in KUBELET_AUTHZ_ARGS variable.
---client-ca-file=<path/to/client-ca-file>
+`--client-ca-file=<path/to/client-ca-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2689,8 +2689,8 @@ to the location of the corresponding private key file.
 If using command line arguments, edit the kubelet service file
 /etc/systemd/system/kubelet.service.d/10-kubeadm.conf on each worker node and
 set the below parameters in KUBELET_CERTIFICATE_ARGS variable.
---tls-cert-file=<path/to/tls-certificate-file>
---tls-private-key-file=<path/to/tls-key-file>
+`--tls-cert-file=<path/to/tls-certificate-file>`
+`--tls-private-key-file=<path/to/tls-key-file>`
 Based on your system, restart the kubelet service. For example:
 systemctl daemon-reload
 systemctl restart kubelet.service
@@ -2925,7 +2925,7 @@ echo "true"
 **Audit Execution:**
 
 ```bash
-./check_for_default_sa.sh 
+./check_for_default_sa.sh
 ```
 
 **Expected Result**:
@@ -3224,7 +3224,7 @@ echo "true"
 **Audit Execution:**
 
 ```bash
-./check_for_rke2_network_policies.sh 
+./check_for_rke2_network_policies.sh
 ```
 
 **Expected Result**:

From 4088a2d716145b34148b5ec128dc502870349bc4 Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 18:13:12 -0700
Subject: [PATCH 7/9] Use backtick instead of quotation to enclose

---
 .../air-gap/install-rancher/install-rancher.md                  | 2 +-
 .../air-gap/install-rancher/install-rancher.md                  | 2 +-
 .../advanced/air-gap-helm2/install-rancher/install-rancher.md   | 2 +-
 .../air-gap/install-rancher/install-rancher.md                  | 2 +-
 .../air-gap/install-rancher/install-rancher.md                  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 548dc51f8c9..73b1f305677 100644
--- a/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -69,7 +69,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 | Chart Option            | Chart Value                      | Description   |
 | ----------------------- | -------------------------------- | ---- |
-| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 8424022cdbc..9d497a7c591 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -68,7 +68,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 | Chart Option            | Chart Value                      | Description   |
 | ----------------------- | -------------------------------- | ---- |
-| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
index fed4dc7a211..753092acb42 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
@@ -70,7 +70,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 | Chart Option            | Chart Value                      | Description   |
 | ----------------------- | -------------------------------- | ---- |
-| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index a6df8ce6ef7..98c4312d0f9 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -76,7 +76,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 | Chart Option            | Chart Value                      | Description   |
 | ----------------------- | -------------------------------- | ---- |
-| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 631cc6c4278..b5025c8c730 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -65,7 +65,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 | Chart Option            | Chart Value                      | Description   |
 | ----------------------- | -------------------------------- | ---- |
-| `certmanager.version` | "<version>" | Configure proper Rancher TLS issuer depending of running cert-manager version. |
+| `certmanager.version` | `<version>` | Configure proper Rancher TLS issuer depending of running cert-manager version. |
 | `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters.  |
 | `useBundledSystemChart` | `true`                           | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. |
 

From 5dc3b086e0ea321fe768daca8454681b59dd1bbf Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 18:18:12 -0700
Subject: [PATCH 8/9] Enclose in backticks so <&tag> aren't processed as HTML
 tags - 3

---
 .../cluster-autoscaler/amazon/amazon.md       | 22 +++++++++----------
 .../rke-1.6-benchmark-2.6.md                  |  6 ++---
 .../rke2-1.6-benchmark-2.6.md                 |  6 ++---
 .../cluster-autoscaler/amazon/amazon.md       | 22 +++++++++----------
 .../cluster-autoscaler/amazon/amazon.md       | 22 +++++++++----------
 .../1.6-benchmark-2.5/1.6-benchmark-2.5.md    |  6 ++---
 .../cluster-autoscaler/amazon/amazon.md       | 22 +++++++++----------
 .../rke-1.6-benchmark-2.6.md                  |  6 ++---
 .../rke2-1.6-benchmark-2.6.md                 |  6 ++---
 9 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/docs/en/cluster-admin/cluster-autoscaler/amazon/amazon.md b/docs/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
index 00ad33025f5..db9e80fd102 100644
--- a/docs/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+++ b/docs/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
@@ -5,7 +5,7 @@ weight: 1
 
 This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
 
-We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. 
+We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
 
 - [Prerequisites](#prerequisites)
 - [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
       }
       ```
 
-2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG. 
+2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
   * IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
 
       ```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
-  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster 
+  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
 
       ```sh
       #!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
 * master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/)
   * IAM role: `K8sMasterRole`
   * Security group: `K8sMasterSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
   * User data: `K8sMasterUserData`
 
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
   * Name: `K8sWorkerAsg`
   * IAM role: `K8sWorkerRole`
   * Security group: `K8sWorkerSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
 
 ### 4. Install Cluster-autoscaler
 
-At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation. 
+At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
 
 #### Parameters
 
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
 |node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
 |scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
 |max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
-|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-cloud-provider|-|Cloud provider type| 
+|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+cloud-provider|-|Cloud provider type|
 |max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
 |max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
 |max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
 |ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
 |scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
 |max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
-|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
+|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
 |node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
 |estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
 |expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -524,7 +524,7 @@ Cluster-autoscaler deployment can also be set up using [manual configuration](ht
 
 # Testing
 
-At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true: 
+At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
 
 * There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
 * There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
diff --git a/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md b/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
index f6bd2a79028..8a979e1b2eb 100644
--- a/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
+++ b/docs/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
@@ -562,7 +562,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --basic-auth-file=<filename> parameter.
+on the master node and remove the `--basic-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -590,7 +590,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --token-auth-file=<filename> parameter.
+on the master node and remove the `--token-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -2177,7 +2177,7 @@ if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
 
 **Remediation:**
 Run the following command to modify the ownership of the --client-ca-file.
-chown root:root <filename>
+`chown root:root <filename>`
 
 **Audit Script:** `check_cafile_ownership.sh`
 
diff --git a/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md b/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
index f97cec92319..1353fd50b30 100644
--- a/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
+++ b/docs/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
@@ -754,7 +754,7 @@ on the master node and set the below parameter.
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
-on the master node and remove the --basic-auth-file=<filename> parameter.
+on the master node and remove the `--basic-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -782,7 +782,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
-on the master node and remove the --token-auth-file=<filename> parameter.
+on the master node and remove the `--token-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -2273,7 +2273,7 @@ stat -c %a /var/lib/rancher/rke2/server/tls/server-ca.crt
 
 **Remediation:**
 Run the following command to modify the ownership of the --client-ca-file.
-chown root:roset: trueot <filename>
+`chown root:roset: trueot <filename>`
 
 **Audit:**
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-autoscaler/amazon/amazon.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
index bd8dfee2fde..cd6961ac739 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
@@ -5,7 +5,7 @@ weight: 1
 
 This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
 
-We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. 
+We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
 
 - [Prerequisites](#prerequisites)
 - [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
       }
       ```
 
-2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG. 
+2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
   * IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
 
       ```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
-  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster 
+  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
 
       ```sh
       #!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
 * master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/production/)
   * IAM role: `K8sMasterRole`
   * Security group: `K8sMasterSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
   * User data: `K8sMasterUserData`
 
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
   * Name: `K8sWorkerAsg`
   * IAM role: `K8sWorkerRole`
   * Security group: `K8sWorkerSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
 
 ### 4. Install Cluster-autoscaler
 
-At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation. 
+At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
 
 #### Parameters
 
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
 |node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
 |scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
 |max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
-|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-cloud-provider|-|Cloud provider type| 
+|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+cloud-provider|-|Cloud provider type|
 |max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
 |max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
 |max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
 |ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
 |scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
 |max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
-|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
+|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
 |node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
 |estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
 |expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -520,7 +520,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
 
 # Testing
 
-At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true: 
+At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
 
 * There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
 * There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-autoscaler/amazon/amazon.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
index 940ea548823..9d0fd642f18 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
@@ -7,7 +7,7 @@ aliases:
 
 This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
 
-We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. 
+We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
 
 - [Prerequisites](#prerequisites)
 - [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -70,7 +70,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
       }
       ```
 
-2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG. 
+2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
   * IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
 
       ```json
@@ -213,7 +213,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
-  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster 
+  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
 
       ```sh
       #!/bin/bash -x
@@ -248,7 +248,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
 * master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/production/)
   * IAM role: `K8sMasterRole`
   * Security group: `K8sMasterSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
   * User data: `K8sMasterUserData`
 
@@ -256,7 +256,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
   * Name: `K8sWorkerAsg`
   * IAM role: `K8sWorkerRole`
   * Security group: `K8sWorkerSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
@@ -270,7 +270,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
 
 ### 4. Install Cluster-autoscaler
 
-At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation. 
+At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
 
 #### Parameters
 
@@ -298,9 +298,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
 |node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
 |scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
 |max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
-|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-cloud-provider|-|Cloud provider type| 
+|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+cloud-provider|-|Cloud provider type|
 |max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
 |max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
 |max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -309,7 +309,7 @@ cloud-provider|-|Cloud provider type|
 |ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
 |scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
 |max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
-|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
+|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
 |node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
 |estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
 |expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -522,7 +522,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
 
 # Testing
 
-At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true: 
+At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
 
 * There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
 * There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
diff --git a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
index f435c8471fa..f34e1ba7984 100644
--- a/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
+++ b/versioned_docs/version-2.5/v2.5/en/security/rancher-2.5/1.6-benchmark-2.5/1.6-benchmark-2.5.md
@@ -651,7 +651,7 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --basic-auth-file=<filename> parameter.
+on the master node and remove the `--basic-auth-file=<filename>` parameter.
 
 
 **Audit:**
@@ -679,7 +679,7 @@ root        4643    4626 22 16:15 ?        00:00:46 kube-apiserver --etcd-keyfil
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --token-auth-file=<filename> parameter.
+on the master node and remove the `--token-auth-file=<filename>` parameter.
 
 
 **Audit:**
@@ -2322,7 +2322,7 @@ if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
 
 **Remediation:**
 Run the following command to modify the ownership of the --client-ca-file.
-chown root:root <filename>
+`chown root:root <filename>`
 
 
 **Audit:**
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-autoscaler/amazon/amazon.md b/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
index ffa5b83b76b..717abd28a43 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-autoscaler/amazon/amazon.md
@@ -5,7 +5,7 @@ weight: 1
 
 This guide will show you how to install and use [Kubernetes cluster-autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/) on Rancher custom clusters using AWS EC2 Auto Scaling Groups.
 
-We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. 
+We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`.
 
 - [Prerequisites](#prerequisites)
 - [1. Create a Custom Cluster](#1-create-a-custom-cluster)
@@ -68,7 +68,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
       }
       ```
 
-2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG. 
+2. Master group: Nodes that will be part of the Kubernetes etcd and/or control planes. This will be out of the ASG.
   * IAM profile: Required by the Kubernetes cloud_provider integration. Optionally, `AWS_ACCESS_KEY` and `AWS_SECRET_KEY` can be used instead [using-aws-credentials.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#using-aws-credentials) This profile is called `K8sMasterProfile`.
 
       ```json
@@ -211,7 +211,7 @@ On AWS EC2, we should create a few objects to configure our system. We've define
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
-  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster 
+  * User data: `K8sWorkerUserData` Ubuntu 18.04(ami-0e11cbb34015ff725), installs docker and add worker node to the k8s cluster
 
       ```sh
       #!/bin/bash -x
@@ -246,7 +246,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
 * master (etcd+controlplane): Depending your needs, deploy three master instances with proper size. More info is at [the recommendations for production-ready clusters.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/)
   * IAM role: `K8sMasterRole`
   * Security group: `K8sMasterSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
   * User data: `K8sMasterUserData`
 
@@ -254,7 +254,7 @@ Once we've configured AWS, let's create VMs to bootstrap our cluster:
   * Name: `K8sWorkerAsg`
   * IAM role: `K8sWorkerRole`
   * Security group: `K8sWorkerSg`
-  * Tags: 
+  * Tags:
     * `kubernetes.io/cluster/<clusterID>: owned`
     * `k8s.io/cluster-autoscaler/<clusterName>: true`
     * `k8s.io/cluster-autoscaler/enabled: true`
@@ -268,7 +268,7 @@ Once the VMs are deployed, you should have a Rancher custom cluster up and runni
 
 ### 4. Install Cluster-autoscaler
 
-At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation. 
+At this point, we should have rancher cluster up and running. We are going to install cluster-autoscaler on master nodes and `kube-system` namespace, following cluster-autoscaler recommendation.
 
 #### Parameters
 
@@ -296,9 +296,9 @@ This table shows cluster-autoscaler parameters for fine tuning:
 |node-deletion-delay-timeout|"2m"|Maximum time CA waits for removing delay-deletion.cluster-autoscaler.kubernetes.io/ annotations before deleting the node|
 |scan-interval|"10s"|How often cluster is reevaluated for scale up or down|
 |max-nodes-total|0|Maximum number of nodes in all node groups. Cluster autoscaler will not grow the cluster beyond this number|
-|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format <min>:<max>. Cluster autoscaler will not scale the cluster beyond these numbers|
-cloud-provider|-|Cloud provider type| 
+|cores-total|"0:320000"|Minimum and maximum number of cores in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+|memory-total|"0:6400000"|Minimum and maximum number of gigabytes of memory in cluster, in the format `<min>:<max>.` Cluster autoscaler will not scale the cluster beyond these numbers|
+cloud-provider|-|Cloud provider type|
 |max-bulk-soft-taint-count|10|Maximum number of nodes that can be tainted/untainted PreferNoSchedule at the same time. Set to 0 to turn off such tainting|
 |max-bulk-soft-taint-time|"3s"|Maximum duration of tainting/untainting nodes as PreferNoSchedule at the same time|
 |max-empty-bulk-delete|10|Maximum number of empty nodes that can be deleted at the same time|
@@ -307,7 +307,7 @@ cloud-provider|-|Cloud provider type|
 |ok-total-unready-count|3|Number of allowed unready nodes, irrespective of max-total-unready-percentage|
 |scale-up-from-zero|true|Should CA scale up when there 0 ready nodes|
 |max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
-|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: <min>:<max>:<other...>|
+|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
 |node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
 |estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
 |expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
@@ -520,7 +520,7 @@ kubectl -n kube-system apply -f cluster-autoscaler-deployment.yaml
 
 # Testing
 
-At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true: 
+At this point, we should have a cluster-scaler up and running in our Rancher custom cluster. Cluster-scale should manage `K8sWorkerAsg` ASG to scale up and down between 2 and 10 nodes, when one of the following conditions is true:
 
 * There are pods that failed to run in the cluster due to insufficient resources. In this case, the cluster is scaled up.
 * There are nodes in the cluster that have been underutilized for an extended period of time and their pods can be placed on other existing nodes. In this case, the cluster is scaled down.
diff --git a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
index 6dc2904182f..3f561e5ff67 100644
--- a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
+++ b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke-1.6-benchmark-2.6/rke-1.6-benchmark-2.6.md
@@ -558,7 +558,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --basic-auth-file=<filename> parameter.
+on the master node and remove the `--basic-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -586,7 +586,7 @@ root 121142 121120 7 12:27 ? 00:06:27 kube-apiserver --audit-log-maxsize=100 --e
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
-on the master node and remove the --token-auth-file=<filename> parameter.
+on the master node and remove the `--token-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -2173,7 +2173,7 @@ if test -e $CAFILE; then stat -c permissions=%a $CAFILE; fi
 
 **Remediation:**
 Run the following command to modify the ownership of the --client-ca-file.
-chown root:root <filename>
+`chown root:root <filename>`
 
 **Audit Script:** `check_cafile_ownership.sh`
 
diff --git a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
index 8e4fc25bbfd..f50043d7cbc 100644
--- a/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
+++ b/versioned_docs/version-2.6/v2.6/en/security/hardening-guides/rke2-1.6-benchmark-2.6/rke2-1.6-benchmark-2.6.md
@@ -750,7 +750,7 @@ on the master node and set the below parameter.
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
-on the master node and remove the --basic-auth-file=<filename> parameter.
+on the master node and remove the `--basic-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -778,7 +778,7 @@ root 5275 5222 15 14:58 ? 00:01:26 kube-apiserver --audit-policy-file=/etc/ranch
 **Remediation:**
 Follow the documentation and configure alternate mechanisms for authentication. Then,
 edit the API server pod specification file /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
-on the master node and remove the --token-auth-file=<filename> parameter.
+on the master node and remove the `--token-auth-file=<filename>` parameter.
 
 **Audit:**
 
@@ -2269,7 +2269,7 @@ stat -c %a /var/lib/rancher/rke2/server/tls/server-ca.crt
 
 **Remediation:**
 Run the following command to modify the ownership of the --client-ca-file.
-chown root:roset: trueot <filename>
+`chown root:roset: trueot <filename>`
 
 **Audit:**
 

From 97f8fd1c09643ebd71bed9c92ee756c035e45431 Mon Sep 17 00:00:00 2001
From: Billy Tat <btat@suse.com>
Date: Mon, 18 Jul 2022 19:12:49 -0700
Subject: [PATCH 9/9] Convert accordion Hugo shortcode to <details> tag

---
 .../rke-config-references.md                  |  15 +-
 .../cloud-providers/azure/azure.md            |  56 +-
 .../install-rancher-on-k8s.md                 |   5 +-
 .../docker-install-commands.md                |  19 +-
 .../install-rancher/install-rancher.md        |   5 +-
 .../single-node-upgrades.md                   |  35 +-
 .../installation/requirements/ports/ports.md  |  40 +-
 .../single-node-install-external-lb.md        |  14 +-
 .../upgrading-cert-manager.md                 |  16 +-
 .../manage-hpa-with-kubectl.md                |  25 +-
 .../testing-hpa/testing-hpa.md                | 956 +++++++++---------
 .../cluster-project-roles.md                  |  14 +-
 .../en/cluster-admin/cluster-admin.md         |   4 +-
 .../editing-clusters/editing-clusters.md      |   2 +-
 .../cluster-provisioning.md                   |   2 +-
 .../hosted-kubernetes-clusters/eks/eks.md     |  20 +-
 .../rke-clusters/options/options.md           |  13 +-
 .../install-rancher-on-k8s.md                 |   5 +-
 .../upgrades/helm2/helm2.md                   |  20 +-
 .../install-rancher/install-rancher.md        |  30 +-
 .../single-node-upgrades.md                   |  35 +-
 .../installation/requirements/ports/ports.md  |  37 +-
 .../installation/requirements/requirements.md |   6 +-
 .../install-rancher/install-rancher.md        |  30 +-
 .../populate-private-registry.md              |  10 +-
 .../helm2/rke-add-on/layer-4-lb/layer-4-lb.md |  10 +-
 .../helm2/rke-add-on/layer-7-lb/layer-7-lb.md |  12 +-
 .../rke-add-on/layer-4-lb/layer-4-lb.md       |  10 +-
 .../rke-add-on/layer-7-lb/layer-7-lb.md       |  13 +-
 .../single-node-install-external-lb.md        |  11 +-
 .../helm-2-instructions.md                    |  19 +-
 .../upgrading-cert-manager.md                 |  18 +-
 .../hpa-for-rancher-before-2_0_7.md           |  19 +-
 .../manage-hpa-with-kubectl.md                |  21 +-
 .../testing-hpa/testing-hpa.md                | 952 ++++++++---------
 .../v2.0-v2.4/en/overview/overview.md         |   4 +-
 .../hardening-2.3.3/hardening-2.3.3.md        | 190 ++--
 .../cluster-project-roles.md                  |  15 +-
 .../v2.5/en/cluster-admin/cluster-admin.md    |   4 +-
 .../editing-clusters/editing-clusters.md      |   2 +-
 .../eks-config-reference.md                   |  12 +-
 .../cluster-provisioning.md                   |   2 +-
 .../cloud-providers/azure/azure.md            |   2 +-
 .../rke-clusters/options/options.md           |   5 +-
 .../install-rancher-on-k8s.md                 |   5 +-
 .../docker-install-commands.md                |  19 +-
 .../install-rancher/install-rancher.md        |   5 +-
 .../single-node-upgrades.md                   |  35 +-
 .../installation/requirements/ports/ports.md  |  42 +-
 .../single-node-install-external-lb.md        |  12 +-
 .../helm-2-instructions.md                    |  20 +-
 .../upgrading-cert-manager.md                 |  19 +-
 .../manage-hpa-with-kubectl.md                |  21 +-
 .../testing-hpa/testing-hpa.md                | 954 ++++++++---------
 .../version-2.5/v2.5/en/overview/overview.md  |   4 +-
 .../v2.6/en/cluster-admin/cluster-admin.md    |   4 +-
 .../editing-clusters/editing-clusters.md      |   2 +-
 .../rke-config-reference.md                   |  15 +-
 .../cluster-provisioning.md                   |   2 +-
 .../cloud-providers/azure/azure.md            |  56 +-
 .../install-rancher-on-k8s.md                 |   5 +-
 .../docker-install-commands.md                |  19 +-
 .../install-rancher/install-rancher.md        |   5 +-
 .../single-node-upgrades.md                   |  38 +-
 .../installation/requirements/ports/ports.md  |  43 +-
 .../single-node-install-external-lb.md        |  12 +-
 .../upgrading-cert-manager.md                 |  17 +-
 .../manage-hpa-with-kubectl.md                |  28 +-
 .../testing-hpa/testing-hpa.md                | 954 ++++++++---------
 .../version-2.6/v2.6/en/overview/overview.md  |   4 +-
 70 files changed, 2731 insertions(+), 2344 deletions(-)

diff --git a/docs/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-references.md b/docs/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-references.md
index 38c1922a15a..2897a604911 100644
--- a/docs/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-references.md
+++ b/docs/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-references.md
@@ -83,7 +83,7 @@ Some advanced configuration options are not exposed in the Rancher UI forms, but
 
 :::
 
-### Kubernetes Version 
+### Kubernetes Version
 
 The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
 
@@ -114,7 +114,7 @@ When Weave is selected as network provider, Rancher will automatically enable en
 
 ### Project Network Isolation
 
-If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication. 
+If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
 
 Project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
 
@@ -141,7 +141,7 @@ The private registry configuration option tells Rancher where to pull the [syste
 - **System images** are components needed to maintain the Kubernetes cluster.
 - **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server.
 
-For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/). 
+For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
 
 Rancher v2.6 introduced the ability to configure [ECR registries for RKE clusters]({{<baseurl>}}/rke/latest/en/config-options/private-registries/#amazon-elastic-container-registry-ecr-private-registry-setup).
 
@@ -169,7 +169,7 @@ For information on using the Rancher UI to set up node pools in an RKE cluster,
 
 If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster.
 
-### Metrics Server Monitoring 
+### Metrics Server Monitoring
 
 Option to enable or disable [Metrics Server]({{<baseurl>}}/rke/latest/en/config-options/add-ons/metrics-server/).
 
@@ -183,7 +183,7 @@ You must have an existing Pod Security Policy configured before you can use this
 
 ### Docker Version on Nodes
 
-Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. 
+Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
 
 If you choose to require a supported Docker version, Rancher will stop pods from running on nodes that don't have a supported Docker version installed.
 
@@ -227,7 +227,8 @@ For the complete reference for configurable options for RKE Kubernetes clusters
 
 RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
 
-{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
+<details id="v2.3.0-cluster-config-file">
+  <summary>Example Cluster Config File</summary>
 
 ```yaml
 #
@@ -319,7 +320,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
   ssh_agent_auth: false
 windows_prefered_cluster: false
 ```
-{{% /accordion %}}
+</details>
 
 ### Default DNS provider
 
diff --git a/docs/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md b/docs/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
index 3bd7d676fd8..e3825bf274f 100644
--- a/docs/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+++ b/docs/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
 
 If you want to use the Azure CLI, you can run the command `az account show` to get the information.
 
-### 2. Set up the Azure Client ID and Azure Client Secret 
+### 2. Set up the Azure Client ID and Azure Client Secret
 
 Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
 
@@ -75,36 +75,38 @@ Only hosts expected to be load balancer back ends need to be in this group.
 
 1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
 
-1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. 
+1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
    * You can click on "Show Advanced" to see more of these automatically generated names and update them if
-   necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. 
+   necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
    * An example is provided below. You will modify it as needed.
 
-    {{% accordion id="v2.6.0-cloud-provider-config-file" label="Example Cloud Provider Config" %}}
+   <details id="v2.6.0-cloud-provider-config-file">
+     <summary>Example Cloud Provider Config</summary>
+
+    ```yaml
+    {
+        "cloud":"AzurePublicCloud",
+        "tenantId": "YOUR TENANTID HERE",
+        "aadClientId": "YOUR AADCLIENTID HERE",
+        "aadClientSecret": "YOUR AADCLIENTSECRET HERE",
+        "subscriptionId": "YOUR SUBSCRIPTIONID HERE",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-KA4jV9V2",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true
+    }
+    ```
+
+    </details>
 
-```yaml
-{   
-    "cloud":"AzurePublicCloud",
-    "tenantId": "YOUR TENANTID HERE",
-    "aadClientId": "YOUR AADCLIENTID HERE",
-    "aadClientSecret": "YOUR AADCLIENTSECRET HERE",
-    "subscriptionId": "YOUR SUBSCRIPTIONID HERE",
-    "resourceGroup": "docker-machine",
-    "location": "westus",
-    "subnetName": "docker-machine",
-    "securityGroupName": "rancher-managed-KA4jV9V2",
-    "securityGroupResourceGroup": "docker-machine",
-    "vnetName": "docker-machine-vnet",
-    "vnetResourceGroup": "docker-machine",
-    "primaryAvailabilitySetName": "docker-machine",
-    "routeTableResourceGroup": "docker-machine",
-    "cloudProviderBackoff": false,
-    "useManagedIdentityExtension": false,
-    "useInstanceMetadata": true
-}
-```
-    {{% /accordion %}}
-    
 1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
 
 1. Click the **Create** button to submit the form and create the cluster.
diff --git a/docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md b/docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
index d8cfa1f5702..c3c309ab70a 100644
--- a/docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+++ b/docs/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
@@ -129,7 +129,8 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen
 
 This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
 
-{{% accordion id="cert-manager" label="Click to Expand" %}}
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
 
 :::note Important:
 
@@ -167,7 +168,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
 cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
 ```
 
-{{% /accordion %}}
+</details>
 
 ### 5. Install Rancher with Helm and Your Chosen Certificate Option
 
diff --git a/docs/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md b/docs/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
index a0c9309ae20..e799fa66a52 100644
--- a/docs/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
+++ b/docs/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
@@ -3,9 +3,9 @@ title: Docker Install Commands
 weight: 1
 ---
 
-The Docker installation is for Rancher users who want to test out Rancher. 
+The Docker installation is for Rancher users who want to test out Rancher.
 
-Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. 
+Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
 
 The backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
 
@@ -27,7 +27,8 @@ Choose from the following options:
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
 
@@ -49,11 +50,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
 
@@ -91,11 +93,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
 
@@ -135,7 +138,7 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 
 
diff --git a/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 73b1f305677..8ef4ef364ed 100644
--- a/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/docs/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -212,7 +212,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
 
 ### For Self-Signed Certificate Installs, Install Cert-manager
 
-{{% accordion id="install-cert-manager" label="Click to expand" %}}
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
 
 If you are using self-signed certificates, install cert-manager:
 
@@ -237,7 +238,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
 kubectl apply -R -f ./cert-manager
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Install Rancher with kubectl
 
diff --git a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 8000be1c114..6f07e2a42b5 100644
--- a/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/docs/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -144,7 +144,8 @@ Select which option you had installed Rancher server
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -162,11 +163,12 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -197,11 +199,12 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
 
@@ -230,11 +233,12 @@ docker run -d --volumes-from rancher-data \
 ```
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+</details>
 
 ### Option D: Let's Encrypt Certificate
 
-{{% accordion id="option-d" label="Click to expand" %}}
+<details id="option-d">
+  <summary>Click to expand</summary>
 
 :::caution
 
@@ -267,7 +271,7 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 <TabItem value="Docker Air Gap Upgrade">
@@ -278,7 +282,8 @@ When starting the new Rancher server container, choose from the following option
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -298,11 +303,12 @@ Placeholder | Description
 ```
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -333,11 +339,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
 
@@ -374,7 +381,7 @@ docker run -d --volumes-from rancher-data \
      <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+</details>
 
 </TabItem>
 </Tabs>
diff --git a/docs/en/installation/requirements/ports/ports.md b/docs/en/installation/requirements/ports/ports.md
index cd63a6deef9..60407c14c97 100644
--- a/docs/en/installation/requirements/ports/ports.md
+++ b/docs/en/installation/requirements/ports/ports.md
@@ -44,7 +44,8 @@ Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3
 
 ### Ports for Rancher Server Nodes on K3s
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The K3s server needs port 6443 to be accessible by the nodes.
 
@@ -79,11 +80,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP      | 2376 | Any node IP from a node created using Node driver        | Docker daemon TLS port used by Docker Machine |
 | TCP      | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
 
@@ -124,11 +126,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 | TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE2
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The RKE2 server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
 
@@ -158,11 +161,12 @@ The VXLAN port on nodes should not be exposed to the world as it opens up your c
 | HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
 
 Typically all outbound traffic is allowed.
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server in Docker
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
 
@@ -182,7 +186,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
 | TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
 | TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
 
-{{% /accordion %}}
+</details>
 
 # Downstream Kubernetes Cluster Nodes
 
@@ -204,7 +208,8 @@ If security isn't a large concern and you're okay with opening a few additional
 
 ### Ports for Rancher Launched Kubernetes Clusters using Node Pools
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/).
 
@@ -216,27 +221,29 @@ The required ports are automatically opened by Rancher during creation of cluste
 
 {{< ports-iaas-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/).
 
 {{< ports-custom-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Hosted Kubernetes Clusters
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Registered Clusters
 
@@ -246,13 +253,14 @@ Registered clusters were called imported clusters before Rancher v2.5.
 
 :::
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [registered clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 
 # Other Port Considerations
diff --git a/docs/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md b/docs/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
index 49868054ed5..6c5e27f7901 100644
--- a/docs/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+++ b/docs/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
@@ -42,7 +42,9 @@ See [Advanced Options](#advanced-options) below before continuing.
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
+
 If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
 
 :::note Prerequisites:
@@ -64,8 +66,10 @@ Create a self-signed certificate.
      rancher/rancher:latest
    ```
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
+
 If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
 
 :::note Prerequisites:
@@ -86,7 +90,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
         rancher/rancher:latest --no-cacerts
         ```
 
-    {{% /accordion %}}
+</details>
 
 ## 3. Configure Load Balancer
 
@@ -216,7 +220,7 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.6/
 
 This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
 
-:::note 
+:::note
 
 This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
 
diff --git a/docs/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md b/docs/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
index 3338dba4646..d71de5e54c8 100644
--- a/docs/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+++ b/docs/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
@@ -28,7 +28,9 @@ In order to upgrade cert-manager, follow these instructions:
 
 ### Option A: Upgrade cert-manager with Internet Access
 
-{{% accordion id="normal" label="Click to expand" %}}
+<details id="normal">
+  <summary>Click to expand</summary>
+
 1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
 
     ```plain
@@ -101,11 +103,12 @@ In order to upgrade cert-manager, follow these instructions:
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Upgrade cert-manager in an Air-Gapped Environment
 
-{{% accordion id="airgap" label="Click to expand" %}}
+<details id="airgap">
+  <summary>Click to expand</summary>
 
 ### Prerequisites
 
@@ -214,11 +217,12 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Upgrade cert-manager from Versions 1.5 and Below
 
-{{% accordion id="normal" label="Click to expand" %}}
+<details id="normal">
+  <summary>Click to expand</summary>
 
 Previously, in order to upgrade cert-manager from an older version, an uninstall and reinstall of Rancher was recommended. Using the method below, you may upgrade cert-manager without those additional steps in order to better preserve your production environment:
 
@@ -239,7 +243,7 @@ Previously, in order to upgrade cert-manager from an older version, an uninstall
 
 1. Upgrade Rancher normally with `helm upgrade`.
 
-{{% /accordion %}}
+</details>
 
 ### Verify the Deployment
 
diff --git a/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md b/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
index 5b1141b1f7c..5de0da5ec27 100644
--- a/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+++ b/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
@@ -64,7 +64,7 @@ spec:
 ```
 
 
-Directive | Description  
+Directive | Description
 ---------|----------|
  `apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
  `name: hello-world` | Indicates that HPA is performing autoscaling for the `hello-word` deployment. |
@@ -76,7 +76,7 @@ Directive | Description
 
 ##### Configuring HPA to Scale Using Resource Metrics (CPU and Memory)
 
-Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler. 
+Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler.
 
 Run the following commands to check if metrics are available in your installation:
 
@@ -158,7 +158,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
     ```
     Then review the log output to confirm the service is running.
-    {{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
+
+    <details id="prometheus-logs">
+      <summary>Prometheus Adaptor Logs</summary>
+
     ...
     I0724 10:18:45.696679       1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
     I0724 10:18:45.696695       1 round_trippers.go:442] Response Headers:
@@ -171,7 +174,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     I0724 10:18:45.699939       1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
     I0724 10:18:51.727845       1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
     ...
-    {{% /accordion %}}
+    </details>
 
 
 
@@ -182,15 +185,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response" label="API Response" %}}
+
+    <details id="custom-metrics-api-response">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
 
   - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
     ```
     # kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
+
+    <details id="custom-metrics-api-response-rancher">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
diff --git a/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/testing-hpa/testing-hpa.md b/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/testing-hpa/testing-hpa.md
index 2d03d3d2d6a..14eeeeeff84 100644
--- a/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/docs/en/k8s-in-rancher/horizontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -9,58 +9,62 @@ For HPA to work correctly, service deployments should have resources request def
 
 1. Configure `kubectl` to connect to your Kubernetes cluster.
 
-2. Copy the `hello-world` deployment manifest below.
-{{% accordion id="hello-world" label="Hello World Manifest" %}}
-```
-apiVersion: apps/v1beta2
-kind: Deployment
-metadata:
-  labels:
-    app: hello-world
-  name: hello-world
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: hello-world
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
-    type: RollingUpdate
-  template:
-    metadata:
-      labels:
-        app: hello-world
-    spec:
-      containers:
-      - image: rancher/hello-world
-        imagePullPolicy: Always
-        name: hello-world
-        resources:
-          requests:
-            cpu: 500m
-            memory: 64Mi
-        ports:
-        - containerPort: 80
-          protocol: TCP
-      restartPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  ports:
-  - port: 80
-    protocol: TCP
-    targetPort: 80
-  selector:
-    app: hello-world
-```
-{{% /accordion %}}
+1. Copy the `hello-world` deployment manifest below.
+
+   <details id="hello-world">
+     <summary>Hello World Manifest</summary>
+
+     ```
+     apiVersion: apps/v1beta2
+     kind: Deployment
+     metadata:
+       labels:
+         app: hello-world
+       name: hello-world
+       namespace: default
+     spec:
+       replicas: 1
+       selector:
+         matchLabels:
+           app: hello-world
+       strategy:
+         rollingUpdate:
+           maxSurge: 1
+           maxUnavailable: 0
+         type: RollingUpdate
+       template:
+         metadata:
+           labels:
+             app: hello-world
+         spec:
+           containers:
+           - image: rancher/hello-world
+             imagePullPolicy: Always
+             name: hello-world
+             resources:
+               requests:
+                 cpu: 500m
+                 memory: 64Mi
+             ports:
+             - containerPort: 80
+               protocol: TCP
+           restartPolicy: Always
+     ---
+     apiVersion: v1
+     kind: Service
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       ports:
+       - port: 80
+         protocol: TCP
+         targetPort: 80
+       selector:
+         app: hello-world
+     ```
+
+   </details>
 
 1. Deploy it to your cluster.
 
@@ -69,423 +73,459 @@ spec:
     ```
 
 1. Copy one of the HPAs below based on the metric type you're using:
-{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 1000Mi
-```
-{{% /accordion %}}
-{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 100Mi
-  - type: Pods
-    pods:
-      metricName: cpu_system
-      targetAverageValue: 20m
-```
-{{% /accordion %}}
+
+   <details id="service-deployment-resource-metrics">
+     <summary>Hello World HPA: Resource Metrics</summary>
+
+      ```
+      apiVersion: autoscaling/v2beta1
+      kind: HorizontalPodAutoscaler
+      metadata:
+        name: hello-world
+        namespace: default
+      spec:
+        scaleTargetRef:
+          apiVersion: extensions/v1beta1
+          kind: Deployment
+          name: hello-world
+        minReplicas: 1
+        maxReplicas: 10
+        metrics:
+        - type: Resource
+          resource:
+            name: cpu
+            targetAverageUtilization: 50
+        - type: Resource
+          resource:
+            name: memory
+            targetAverageValue: 1000Mi
+      ```
+
+   </details>
+   <details id="service-deployment-custom-metrics">
+     <summary>Hello World HPA: Custom Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 100Mi
+       - type: Pods
+         pods:
+           metricName: cpu_system
+           targetAverageValue: 20m
+     ```
+
+   </details>
 
 1. View the HPA info and description. Confirm that metric data is shown.
-    {{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
-1. Enter the following commands.
-    ```
-    # kubectl get hpa
-    NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
-    hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
-    # kubectl describe hpa
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             1253376 / 100Mi
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
-    {{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive the output that follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             3514368 / 100Mi
-      "cpu_system" on pods:                                0 / 20m
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
 
+   <details id="hpa-info-resource-metrics">
+     <summary>Resource Metrics</summary>
+
+      1. Enter the following commands.
+          ```
+          # kubectl get hpa
+          NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
+          hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
+          # kubectl describe hpa
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             1253376 / 100Mi
+            resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:           <none>
+          ```
+
+   </details>
+   <details id="hpa-info-custom-metrics">
+     <summary>Custom Metrics</summary>
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive the output that follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             3514368 / 100Mi
+           "cpu_system" on pods:                                0 / 20m
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
 1. Test that pod autoscaling works as intended.<br/><br/>
-  **To Test Autoscaling Using Resource Metrics:**
-  {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to two pods based on CPU Usage.
+   **To Test Autoscaling Using Resource Metrics:**
 
-1. View your HPA.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive output similar to what follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             10928128 / 100Mi
-      resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-      ```
-1. Enter the following command to confirm you've scaled to two pods.
-   ```
-      # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-   ```
-  {{% /accordion %}}
-  {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
+   <details id="observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             9424896 / 100Mi
-        resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-    ```
-2. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-    You should receive output similar to what follows.
-     ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-      ```
-  {{% /accordion %}}
-  {{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+     Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             10070016 / 100Mi
-        resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-  ```
-  {{% /accordion %}}
-<br/>
-**To Test Autoscaling Using Custom Metrics:**
-  {{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale two pods based on CPU usage.
+     1. View your HPA.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive output similar to what follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             10928128 / 100Mi
+           resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+           ```
+     1. Enter the following command to confirm you've scaled to two pods.
+        ```
+           # kubectl get pods
+        ```
+        You should receive output similar to what follows:
+        ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+        ```
 
-1. Enter the following command.
-  ```
-    # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             8159232 / 100Mi
-      "cpu_system" on pods:                                7m / 20m
-      resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-  ```
-1. Enter the following command to confirm two pods are running.
-  ```
-    # kubectl get pods
-  ```
-  You should receive output similar to what follows.
-  ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-  ```
-  {{% /accordion %}}
-{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown">
+     <summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows:
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-    ```
-1. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      # kubectl get pods
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-   ```
-{{% /accordion %}}
-{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+     Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-        Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-    ```
-1.  Enter the following command to confirm four pods are running.
-    ```
-    # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
-{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
-
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive similar output to what follows.
-    ```
-        Name:                                                  hello-world
-        Namespace:                                             default
-        Labels:                                                <none>
-        Annotations:                                           <none>
-        CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-        Reference:                                             Deployment/hello-world
-        Metrics:                                               ( current / target )
-          resource memory on pods:                             8101888 / 100Mi
-          "cpu_system" on pods:                                8m / 20m
-          resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-        Min replicas:                                          1
-        Max replicas:                                          10
-        Conditions:
-          Type            Status  Reason              Message
-          ----            ------  ------              -------
-          AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-          ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-          ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-        Events:
-          Type    Reason             Age   From                       Message
-          ----    ------             ----  ----                       -------
-          Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-          Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-          Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-          Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-    ```
-1. Enter the following command to confirm a single pods is running.
-    ```
+     1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows
+        ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             9424896 / 100Mi
+             resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+         ```
+     2. Enter the following command to confirm three pods are running.
+        ```
         # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
+        ```
+         You should receive output similar to what follows.
+          ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+           ```
+
+   </details>
+   <details id="observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+    Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+
+    1. Enter the following command.
+      ```
+      # kubectl describe hpa
+      ```
+      You should receive output similar to what follows.
+      ```
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             10070016 / 100Mi
+            resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:
+            Type    Reason             Age   From                       Message
+            ----    ------             ----  ----                       -------
+            Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+      ```
+
+   </details>
+
+   **To Test Autoscaling Using Custom Metrics:**
+
+   <details id="custom-observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale two pods based on CPU usage.
+
+     1. Enter the following command.
+       ```
+         # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             8159232 / 100Mi
+           "cpu_system" on pods:                                7m / 20m
+           resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+       ```
+     1. Enter the following command to confirm two pods are running.
+       ```
+         # kubectl get pods
+       ```
+       You should receive output similar to what follows.
+       ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown-2">
+    <summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
+
+    Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+
+    1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows:
+       ```
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             8374272 / 100Mi
+            "cpu_system" on pods:                                27m / 20m
+            resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:
+            Type    Reason             Age   From                       Message
+            ----    ------             ----  ----                       -------
+            Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+        ```
+    1. Enter the following command to confirm three pods are running.
+       ```
+       # kubectl get pods
+       ```
+       You should receive output similar to what follows:
+       ```
+          # kubectl get pods
+          NAME                           READY     STATUS    RESTARTS   AGE
+          hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
+          hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+          hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-4-pods">
+     <summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
+
+      Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+
+      1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows.
+        ```
+            Name:                                                  hello-world
+            Namespace:                                             default
+            Labels:                                                <none>
+            Annotations:                                           <none>
+            CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+            Reference:                                             Deployment/hello-world
+            Metrics:                                               ( current / target )
+              resource memory on pods:                             8374272 / 100Mi
+              "cpu_system" on pods:                                27m / 20m
+              resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+            Min replicas:                                          1
+            Max replicas:                                          10
+            Conditions:
+              Type            Status  Reason              Message
+              ----            ------  ------              -------
+              AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+              ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+              ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+            Events:
+              Type    Reason             Age   From                       Message
+              ----    ------             ----  ----                       -------
+              Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+              Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+              Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+          ```
+      1.  Enter the following command to confirm four pods are running.
+          ```
+          # kubectl get pods
+          ```
+          You should receive output similar to what follows.
+          ```
+            NAME                           READY     STATUS    RESTARTS   AGE
+            hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
+            hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
+            hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+            hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+          ```
+
+   </details>
+   <details id="custom-metrics-observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive similar output to what follows.
+         ```
+             Name:                                                  hello-world
+             Namespace:                                             default
+             Labels:                                                <none>
+             Annotations:                                           <none>
+             CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+             Reference:                                             Deployment/hello-world
+             Metrics:                                               ( current / target )
+               resource memory on pods:                             8101888 / 100Mi
+               "cpu_system" on pods:                                8m / 20m
+               resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+             Min replicas:                                          1
+             Max replicas:                                          10
+             Conditions:
+               Type            Status  Reason              Message
+               ----            ------  ------              -------
+               AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+               ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+               ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+             Events:
+               Type    Reason             Age   From                       Message
+               ----    ------             ----  ----                       -------
+               Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+               Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+               Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+               Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+         ```
+     1. Enter the following command to confirm a single pods is running.
+         ```
+             # kubectl get pods
+         ```
+         You should receive output similar to what follows.
+         ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+         ```
+
+   </details>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
index 780ca747935..d2d1c927927 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
@@ -164,14 +164,20 @@ You can change the cluster or project role(s) that are automatically assigned to
 1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **&#8942; > Edit**.
 
 1. Enable the role as default.
-{{% accordion id="cluster" label="For Clusters" %}}
+<details id="cluster">
+  <summary>For Clusters</summary>
+
 1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
 1. Click **Save**.
-{{% /accordion %}}
-{{% accordion id="project" label="For Projects" %}}
+
+</details>
+<details id="project">
+
+  <summary>For Projects</summary>
 1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
 1. Click **Save**.
-{{% /accordion %}}
+
+</details>
 
 1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-admin.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-admin.md
index 29946116c56..5b8020904da 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-admin.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/cluster-admin.md
@@ -21,9 +21,9 @@ Alternatively, you can switch between projects and clusters directly in the navi
 
 ## Managing Clusters in Rancher
 
-After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster. 
+After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
 
-{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 ## Configuring Tools
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/editing-clusters/editing-clusters.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/editing-clusters/editing-clusters.md
index 904417b914c..d220ec82996 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/editing-clusters/editing-clusters.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-admin/editing-clusters/editing-clusters.md
@@ -18,7 +18,7 @@ The options and settings available for an existing cluster change based on the m
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 ### Editing Clusters in the Rancher UI
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/cluster-provisioning.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/cluster-provisioning.md
index 7e5a757a272..c4780161c18 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/cluster-provisioning.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/cluster-provisioning.md
@@ -28,7 +28,7 @@ This section covers the following topics:
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 # Setting up Clusters in a Hosted Kubernetes Provider
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/eks.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/eks.md
index 4bbe6983d39..1e7fba46ed2 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/eks.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/eks.md
@@ -68,17 +68,17 @@ Use Rancher to set up and configure your Kubernetes cluster.
 
 1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
 
-1. Fill out the rest of the form. For help, refer to the [configuration reference.](#eks-cluster-configuration-reference) 
+1. Fill out the rest of the form. For help, refer to the [configuration reference.](#eks-cluster-configuration-reference)
 
 1. Click **Create**.
 
-**Result:** 
+**Result:**
 
 Your cluster is created and assigned a state of **Provisioning.** Rancher is standing up your cluster.
 
 You can access your cluster after its state is updated to **Active.**
 
-**Active** clusters are assigned two Projects: 
+**Active** clusters are assigned two Projects:
 
 - `Default`, containing the `default` namespace
 - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
@@ -139,7 +139,8 @@ Option | Description
 
 If you choose to assign a public IP address to your cluster's worker nodes, you have the option of choosing between a VPC that's automatically generated by Rancher (i.e., **Standard: Rancher generated VPC and Subnet**), or a VPC that you've already created with AWS (i.e., **Custom: Choose from your existing VPC and Subnets**). Choose the option that best fits your use case.
 
-{{% accordion id="yes" label="Click to expand" %}}
+<details id="yes">
+  <summary>Click to expand</summary>
 
 If you're using **Custom: Choose from your existing VPC and Subnets**:
 
@@ -152,10 +153,13 @@ If you're using **Custom: Choose from your existing VPC and Subnets**:
 1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
 
 1. Click **Next: Select Security Group**.
-{{% /accordion %}}
+</details>
 
 If your worker nodes have Private IPs only, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
-{{% accordion id="no" label="Click to expand" %}}
+
+<details id="no">
+  <summary>Click to expand</summary>
+
 Follow the steps below.
 
 >**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set.  The private set should have its route tables configured to point toward a NAT in the public set.  For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
@@ -164,7 +168,7 @@ Follow the steps below.
 
 1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
 
-{{% /accordion %}}
+</details>
 
 ### Security Group
 
@@ -215,7 +219,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
 
 Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration.
 
-Resource | Description 
+Resource | Description
 ---------|------------
 Service Role | The service role provides Kubernetes the permissions it requires to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/#service-role-permissions).
 VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters/eks/#vpc-permissions).
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/options.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/options.md
index a02c277da87..7ede5064def 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/options.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/options.md
@@ -59,7 +59,7 @@ Out of the box, Rancher is compatible with the following network providers:
 - [Weave](https://github.com/weaveworks/weave) (Available as of v2.2.0)
 
 **Notes on Canal:**
-  
+
 In v2.0.0 - v2.0.4 and v2.0.6, this was the default option for these clusters was Canal with network isolation. With the network isolation automatically enabled, it prevented any pod communication between [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/).
 
 As of v2.0.7, if you use Canal, you also have the option of using **Project Network Isolation**, which will enable or disable communication between pods in different [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/).
@@ -169,7 +169,8 @@ The structure of the config file is different depending on your version of Ranch
 
 RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
 
-{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.3.0+" %}}
+<details id="v2.3.0-cluster-config-file">
+  <summary>Example Cluster Config File for Rancher v2.3.0+</summary>
 
 ```yaml
 #
@@ -261,13 +262,15 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
   ssh_agent_auth: false
 windows_prefered_cluster: false
 ```
-{{% /accordion %}}
+</details>
 
 ### Config File Structure in Rancher v2.0.0-v2.2.x
 
 An example cluster config file is included below.
 
-{{% accordion id="before-v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.0.0-v2.2.x" %}}
+<details id="before-v2.3.0-cluster-config-file">
+  <summary>Example Cluster Config File for Rancher v2.0.0-v2.2.x</summary>
+
 ```yaml
 addon_job_timeout: 30
 authentication:
@@ -344,7 +347,7 @@ services:
     service_node_port_range: 30000-32767
 ssh_agent_auth: false
 ```
-{{% /accordion %}}
+</details>
 
 ### Default DNS provider
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
index ce99003d2e7..074025d6377 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
@@ -103,7 +103,8 @@ There are three recommended options for the source of the certificate used for T
 
 This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
 
-{{% accordion id="cert-manager" label="Click to Expand" %}}
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
 
 > **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/upgrading-cert-manager/).
 
@@ -150,7 +151,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
 cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
 ```
 
-{{% /accordion %}}
+</details>
 
 ### 6. Install Rancher with Helm and Your Chosen Certificate Option
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md
index 412d381a37c..868aab2c23f 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/helm2.md
@@ -102,7 +102,8 @@ hostname: rancher.my.org
 
 If you are also upgrading cert-manager to the latest version from a version older than 0.11.0, follow `Option B: Reinstalling Rancher`. Otherwise, follow `Option A: Upgrading Rancher`.
 
-{{% accordion label="Option A: Upgrading Rancher" %}}
+<details>
+  <summary>Option A: Upgrading Rancher</summary>
 
 Upgrade Rancher to the latest version with all your settings.
 
@@ -113,9 +114,10 @@ helm upgrade --install rancher rancher-<CHART_REPO>/rancher \
   --namespace cattle-system \
   --set hostname=rancher.my.org
 ```
-{{% /accordion %}}
+</details>
 
-{{% accordion label="Option B: Reinstalling Rancher chart" %}}
+<details>
+  <summary>Option B: Reinstalling Rancher chart</summary>
 
 If you are currently running the cert-manager whose version is older than v0.11, and want to upgrade both Rancher and cert-manager to a newer version, then you need to reinstall both Rancher and cert-manager due to the API change in cert-manager v0.11.
 
@@ -137,7 +139,7 @@ If you are currently running the cert-manager whose version is older than v0.11,
     --set hostname=rancher.my.org
     ```
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 <TabItem value="Kubernetes Air Gap Upgrade">
@@ -153,7 +155,8 @@ If you are currently running the cert-manager whose version is older than v0.11,
     `<REGISTRY.YOURDOMAIN.COM:PORT>` | The DNS name for your private registry.
     `<CERTMANAGER_VERSION>` | Cert-manager version running on k8s cluster.
 
-{{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}}
+<details id="self-signed">
+  <summary>Option A-Default Self-Signed Certificate</summary>
 
  ```plain
 helm template ./rancher-<VERSION>.tgz --output-dir . \
@@ -166,8 +169,9 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
  --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
 ```
 
-{{% /accordion %}}
-{{% accordion id="secret" label="Option B: Certificates From Files using Kubernetes Secrets" %}}
+</details>
+<details id="secret">
+  <summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
 
 ```plain
 helm template ./rancher-<VERSION>.tgz --output-dir . \
@@ -194,7 +198,7 @@ helm template ./rancher-<VERSION>.tgz --output-dir . \
 --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
 ```
 
-{{% /accordion %}}
+</details>
 
 2. Copy the rendered manifest directories to a system with access to the Rancher server cluster and apply the rendered templates.
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 9d497a7c591..48f312f546d 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -76,7 +76,8 @@ Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-yo
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="k8s-1" label="Click to expand" %}}
+<details id="k8s-1">
+  <summary>Click to expand</summary>
 
 By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
 
@@ -131,11 +132,12 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat
 
 **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.3.6`
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Certificates From Files using Kubernetes Secrets
 
-{{% accordion id="k8s-2" label="Click to expand" %}}
+<details id="k8s-2">
+  <summary>Click to expand</summary>
 
 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
 
@@ -174,7 +176,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
 
 Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/encryption/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
 
-{{% /accordion %}}
+</details>
 
 # 4. Install Rancher
 
@@ -186,7 +188,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
 
 ### For Self-Signed Certificate Installs, Install Cert-manager
 
-{{% accordion id="install-cert-manager" label="Click to expand" %}}
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
 
 If you are using self-signed certificates, install cert-manager:
 
@@ -208,7 +211,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
 kubectl apply -R -f ./cert-manager
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Install Rancher with kubectl
 
@@ -259,7 +262,8 @@ Choose from the following options:
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
 
@@ -278,11 +282,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
 
@@ -316,11 +321,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
 
@@ -349,7 +355,7 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 If you are installing Rancher v2.3.0+, the installation is complete.
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index be22dd5f101..b3d2643849d 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -140,7 +140,8 @@ Select which option you had installed Rancher server
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -155,11 +156,12 @@ docker run -d --volumes-from rancher-data \
   rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -184,11 +186,12 @@ docker run -d --volumes-from rancher-data \
 ```
 
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
 
@@ -211,11 +214,12 @@ docker run -d --volumes-from rancher-data \
   --no-cacerts
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option D: Let's Encrypt Certificate
 
-{{% accordion id="option-d" label="Click to expand" %}}
+<details id="option-d">
+  <summary>Click to expand</summary>
 
 >**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
 
@@ -239,7 +243,7 @@ docker run -d --volumes-from rancher-data \
   --acme-domain <YOUR.DNS.NAME>
 ```
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 <TabItem value="Docker Air Gap Upgrade">
@@ -252,7 +256,8 @@ When starting the new Rancher server container, choose from the following option
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -270,11 +275,12 @@ Placeholder | Description
       <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -299,11 +305,12 @@ docker run -d --restart=unless-stopped \
     -e CATTLE_SYSTEM_CATALOG=bundled \ #Available as of v2.3.0, use the packaged Rancher system charts
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
 
@@ -331,7 +338,7 @@ docker run -d --volumes-from rancher-data \
      <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 </Tabs>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/ports/ports.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/ports/ports.md
index 682497174d5..d4661e7cbe3 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/ports/ports.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/ports/ports.md
@@ -35,7 +35,8 @@ The port requirements differ based on the Rancher server architecture.
 
 ### Ports for Rancher Server Nodes on K3s
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The K3s server needs port 6443 to be accessible by the nodes.
 
@@ -66,11 +67,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP      | 2376 | Any node IP from a node created using Node driver        | Docker daemon TLS port used by Docker Machine |
 | TCP      | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
 
@@ -110,11 +112,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 | TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server in Docker
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
 
@@ -134,7 +137,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
 | TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
 | TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
 
-{{% /accordion %}}
+</details>
 
 # Downstream Kubernetes Cluster Nodes
 
@@ -154,7 +157,8 @@ The following diagram depicts the ports that are opened for each [cluster type](
 
 ### Ports for Rancher Launched Kubernetes Clusters using Node Pools
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/).
 
@@ -163,38 +167,41 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
 
 {{< ports-iaas-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/custom-nodes/).
 
 {{< ports-custom-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Hosted Kubernetes Clusters
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/hosted-kubernetes-clusters).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Imported Clusters
 
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [imported clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/imported-clusters/).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 
 # Other Port Considerations
@@ -203,7 +210,7 @@ The following table depicts the port requirements for [imported clusters]({{<bas
 
 These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
 
-{{% include file="/rancher/v2.0-v2.4/en/installation/requirements/ports/common-ports-table" %}}
+{{% include file="/rancher/v2.0-v2.4/en/installation/requirements/ports/common-ports-table</summary>
 
 ----
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md
index d44dd6b7be5..d8eeb45d2ba 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/requirements/requirements.md
@@ -116,7 +116,9 @@ These requirements apply to a host with a [single-node]({{<baseurl>}}/rancher/v2
 
 ### CPU and Memory for Rancher before v2.4.0
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
+
 These requirements apply to installing Rancher on an RKE Kubernetes cluster before Rancher v2.4.0:
 
 | Deployment Size | Clusters  | Nodes      | vCPUs                                           | RAM                                             |
@@ -126,7 +128,7 @@ These requirements apply to installing Rancher on an RKE Kubernetes cluster befo
 | Large           | Up to 50  | Up to 500  | 8                                               | 32 GB                                           |
 | X-Large         | Up to 100 | Up to 1000 | 32                                              | 128 GB                                          |
 | XX-Large        | 100+      | 1000+      | [Contact Rancher](https://rancher.com/contact/) | [Contact Rancher](https://rancher.com/contact/) |
-{{% /accordion %}}
+</details>
 
 ### Disks
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
index 753092acb42..5eb8525e182 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md
@@ -76,7 +76,8 @@ When setting up the Rancher Helm template, there are several options in the Helm
 
 Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), complete one of the procedures below.
 
-{{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}}
+<details id="self-signed">
+  <summary>Option A-Default Self-Signed Certificate</summary>
 
 By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface.
 
@@ -129,9 +130,10 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat
      --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
 ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="secret" label="Option B: Certificates From Files using Kubernetes Secrets" %}}
+<details id="secret">
+  <summary>Option B: Certificates From Files using Kubernetes Secrets</summary>
 
 Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher.
 
@@ -170,7 +172,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
 
 Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
 
-{{% /accordion %}}
+</details>
 
 ### D. Install Rancher
 
@@ -180,7 +182,8 @@ Use `kubectl` to create namespaces and apply the rendered manifests.
 
 If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
 
-{{% accordion id="install-cert-manager" label="Self-Signed Certificate Installs - Install Cert-manager" %}}
+<details id="install-cert-manager">
+  <summary>Self-Signed Certificate Installs - Install Cert-manager</summary>
 
 If you are using self-signed certificates, install cert-manager:
 
@@ -202,7 +205,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
 kubectl apply -R -f ./cert-manager
 ```
 
-{{% /accordion %}}
+</details>
 
 Install Rancher:
 
@@ -246,7 +249,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A-Default Self-Signed Certificate" %}}
+<details id="option-a">
+  <summary>Option A-Default Self-Signed Certificate</summary>
 
 If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
 
@@ -265,8 +269,9 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}}
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Self-Signed</summary>
 
 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
 
@@ -298,8 +303,9 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
-{{% accordion id="option-c" label="Option C-Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-c">
+  <summary>Option C-Bring Your Own Certificate: Signed by Recognized CA</summary>
 
 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
 
@@ -328,7 +334,7 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 If you are installing Rancher v2.3.0+, the installation is complete.
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
index 0fe9734c28d..57cf8d5c83a 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md
@@ -120,7 +120,8 @@ B. Save the images to your Windows Server workstation <br/>
 C. Prepare the Docker daemon <br/>
 D. Populate the private registry
 
-{{% accordion label="Collecting and Populating Windows Images into the Private Registry"%}}
+<details>
+  <summary>Collecting and Populating Windows Images into the Private Registry"%}}
 
 ### Prerequisites
 
@@ -183,7 +184,7 @@ Move the images in the `rancher-windows-images.tar.gz` to your private registry
    ./rancher-load-images.ps1 --registry <REGISTRY.YOURDOMAIN.COM:PORT>
    ```
 
-{{% /accordion %}}
+</details>
 
 ### Linux Steps
 
@@ -194,7 +195,8 @@ B. Collect all the required images <br/>
 C. Save the images to your Linux workstation <br/>
 D. Populate the private registry
 
-{{% accordion label="Collecting and Populating Linux Images into the Private Registry" %}}
+<details>
+  <summary>Collecting and Populating Linux Images into the Private Registry</summary>
 
 ### Prerequisites
 
@@ -270,7 +272,7 @@ Move the images in the `rancher-images.tar.gz` to your private registry using th
      --registry <REGISTRY.YOURDOMAIN.COM:PORT>
    ```
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 </Tabs>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-4-lb/layer-4-lb.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-4-lb/layer-4-lb.md
index 7a84ec93609..8635d687969 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-4-lb/layer-4-lb.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-4-lb/layer-4-lb.md
@@ -220,7 +220,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
 
 >**Prerequisites:**
 >Create a self-signed certificate.
@@ -272,9 +273,10 @@ Choose from the following options:
       cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
     ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
 
 If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
 
@@ -301,7 +303,7 @@ data:
   tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
 ```
 
-{{% /accordion %}}
+</details>
 
 
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-7-lb/layer-7-lb.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-7-lb/layer-7-lb.md
index 0dbb1290d64..964be334f5c 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-7-lb/layer-7-lb.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/layer-7-lb/layer-7-lb.md
@@ -169,7 +169,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
 >**Prerequisites:**
 >Create a self-signed certificate.
 >
@@ -193,10 +195,12 @@ After replacing the values, the file should look like the example below (the bas
         data:
             cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
 If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
-{{% /accordion %}}
+</details>
 
 ## 8. Configure FQDN
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-4-lb/layer-4-lb.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-4-lb/layer-4-lb.md
index cb9001f3484..dfa49037e43 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-4-lb/layer-4-lb.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-4-lb/layer-4-lb.md
@@ -218,7 +218,8 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
 
 >**Prerequisites:**
 >Create a self-signed certificate.
@@ -270,9 +271,10 @@ Choose from the following options:
       cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
     ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
 
 If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the intermediate certificates in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
 
@@ -299,7 +301,7 @@ data:
   tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
 ```
 
-{{% /accordion %}}
+</details>
 
 
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-7-lb/layer-7-lb.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-7-lb/layer-7-lb.md
index 236813e01e0..c743c28edd3 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-7-lb/layer-7-lb.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/rke-add-on/layer-7-lb/layer-7-lb.md
@@ -166,7 +166,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A—Bring Your Own Certificate: Self-Signed</summary>
+
 >**Prerequisites:**
 >Create a self-signed certificate.
 >
@@ -190,10 +192,13 @@ After replacing the values, the file should look like the example below (the bas
         data:
             cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B—Bring Your Own Certificate: Signed by Recognized CA</summary>
+
 If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
-{{% /accordion %}}
+
+</details>
 
 ## 8. Configure FQDN
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
index cf9a01efa25..3666bddd71d 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
@@ -48,7 +48,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
+
 If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
 
 > **Prerequisites:**
@@ -67,8 +69,9 @@ If you elect to use a self-signed certificate to encrypt communication, you must
      rancher/rancher:latest
    ```
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
 If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
 
 > **Prerequisites:**
@@ -87,7 +90,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
         rancher/rancher:latest --no-cacerts
         ```
 
-    {{% /accordion %}}
+</details>
 
 ## 3. Configure Load Balancer
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
index 968cd6d6666..75436d079e3 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
@@ -23,22 +23,23 @@ To address these changes, this guide will do two things:
 
 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
-> 3. Install the newer version of Rancher and cert-manager 
+> 3. Install the newer version of Rancher and cert-manager
 
 > The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
 
-> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section. 
+> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
 
-## Upgrade Cert-Manager Only 
+## Upgrade Cert-Manager Only
 
 > **Note:**
-> These instructions are applied if you have no plan to upgrade Rancher. 
+> These instructions are applied if you have no plan to upgrade Rancher.
 
 The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.
 
 In order to upgrade cert-manager, follow these instructions:
 
-{{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}}
+<details id="normal">
+  <summary>Upgrading cert-manager with Internet access</summary>
 1. Back up existing resources as a precaution
 
     ```plain
@@ -74,9 +75,11 @@ In order to upgrade cert-manager, follow these instructions:
     ```plain
     helm install --version 0.12.0 --name cert-manager --namespace kube-system jetstack/cert-manager
     ```
-{{% /accordion %}}
+</details>
+
+<details id="airgap">
+  <summary>Upgrading cert-manager in an airgapped environment</summary>
 
-{{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}}
 ### Prerequisites
 
 Before you can perform the upgrade, you must prepare your air gapped environment by adding the necessary container images to your private registry and downloading or rendering the required Kubernetes manifest files.
@@ -138,7 +141,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     ```plain
     kubectl -n kube-system apply -R -f ./cert-manager
     ```
-{{% /accordion %}}
+</details>
 
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
index 29d2e411443..e4e1b6ad47d 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
@@ -23,11 +23,11 @@ To address these changes, this guide will do two things:
 
 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
-> 3. Install the newer version of Rancher and cert-manager 
+> 3. Install the newer version of Rancher and cert-manager
 
 > The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
 
-> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section. 
+> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
 
 # Upgrade Cert-Manager
 
@@ -39,7 +39,8 @@ In order to upgrade cert-manager, follow these instructions:
 
 ### Option A: Upgrade cert-manager with Internet Access
 
-{{% accordion id="normal" label="Click to expand" %}}
+<details id="normal">
+  <summary>Click to expand</summary>
 1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
 
     ```plain
@@ -95,7 +96,7 @@ In order to upgrade cert-manager, follow these instructions:
     helm install \
       cert-manager jetstack/cert-manager \
       --namespace cert-manager \
-      --version v0.12.0 
+      --version v0.12.0
     ```
 
 1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -104,11 +105,12 @@ In order to upgrade cert-manager, follow these instructions:
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Upgrade cert-manager in an Air Gap Environment
 
-{{% accordion id="airgap" label="Click to expand" %}}
+<details id="airgap">
+  <summary>Click to expand</summary>
 
 ### Prerequisites
 
@@ -211,9 +213,9 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
-### Verify the Deployment 
+### Verify the Deployment
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
 
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/hpa-for-rancher-before-2_0_7/hpa-for-rancher-before-2_0_7.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/hpa-for-rancher-before-2_0_7/hpa-for-rancher-before-2_0_7.md
index 2c819769302..79a39eb73d6 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/hpa-for-rancher-before-2_0_7/hpa-for-rancher-before-2_0_7.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/hpa-for-rancher-before-2_0_7/hpa-for-rancher-before-2_0_7.md
@@ -80,7 +80,10 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
     # kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
     ```
     Then review the log to confirm that the `metrics-server` package is running.
-    {{% accordion id="metrics-server-run-check" label="Metrics Server Log Output" %}}
+
+    <details id="metrics-server-run-check">
+  <summary>Metrics Server Log Output</summary>
+
     I0723 08:09:56.193136       1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:''
     I0723 08:09:56.193574       1 heapster.go:72] Metrics Server version v0.2.1
     I0723 08:09:56.194480       1 configs.go:61] Using Kubernetes client with master "https://10.43.0.1:443" and version
@@ -91,7 +94,7 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
     [restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
     [restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
     I0723 08:09:57.394080       1 serve.go:85] Serving securely on 0.0.0.0:443
-    {{% /accordion %}}
+    </details>
 
 
 1. Check that the metrics api is accessible from `kubectl`.
@@ -124,7 +127,10 @@ To do it, follow these steps:
 1. Configure `kubectl` to connect to your cluster.
 
 1. Copy the ClusterRole and ClusterRoleBinding manifest for the type of metrics you're using for your HPA.
-  {{% accordion id="cluster-role-resource-metrics" label="Resource Metrics: ApiGroups resource.metrics.k8s.io" %}}
+
+  <details id="cluster-role-resource-metrics">
+  <summary>Resource Metrics: ApiGroups resource.metrics.k8s.io</summary>
+
         apiVersion: rbac.authorization.k8s.io/v1
         kind: ClusterRole
         metadata:
@@ -152,8 +158,9 @@ To do it, follow these steps:
           - apiGroup: rbac.authorization.k8s.io
             kind: User
             name: system:anonymous
-    {{% /accordion %}}
-{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
+    </details>
+<details id="cluster-role-custom-resources">
+  <summary>Custom Metrics: ApiGroups custom.metrics.k8s.io</summary>
 
   ```
   apiVersion: rbac.authorization.k8s.io/v1
@@ -183,7 +190,7 @@ To do it, follow these steps:
       kind: User
       name: system:anonymous
   ```
-{{% /accordion %}}
+</details>
 1. Create them in your cluster using one of the follow commands, depending on the metrics you're using.
  ```
   # kubectl create -f <RESOURCE_METRICS_MANIFEST>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
index 6857b0ce295..9a67085107c 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
@@ -164,7 +164,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
     ```
     Then review the log output to confirm the service is running.
-    {{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
+
+    <details id="prometheus-logs">
+  <summary>Prometheus Adaptor Logs</summary>
+
     ...
     I0724 10:18:45.696679       1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
     I0724 10:18:45.696695       1 round_trippers.go:442] Response Headers:
@@ -177,7 +180,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     I0724 10:18:45.699939       1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
     I0724 10:18:51.727845       1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
     ...
-    {{% /accordion %}}
+    </details>
 
 
 
@@ -188,15 +191,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response" label="API Response" %}}
+
+    <details id="custom-metrics-api-response">
+  <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
 
   - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
     ```
     # kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
+
+    <details id="custom-metrics-api-response-rancher">
+  <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
index 682484fc664..9e488b4ffc8 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -12,58 +12,62 @@ For HPA to work correctly, service deployments should have resources request def
 
 1. Configure `kubectl` to connect to your Kubernetes cluster.
 
-2. Copy the `hello-world` deployment manifest below.
-{{% accordion id="hello-world" label="Hello World Manifest" %}}
-```
-apiVersion: apps/v1beta2
-kind: Deployment
-metadata:
-  labels:
-    app: hello-world
-  name: hello-world
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: hello-world
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
-    type: RollingUpdate
-  template:
-    metadata:
-      labels:
-        app: hello-world
-    spec:
-      containers:
-      - image: rancher/hello-world
-        imagePullPolicy: Always
-        name: hello-world
-        resources:
-          requests:
-            cpu: 500m
-            memory: 64Mi
-        ports:
-        - containerPort: 80
-          protocol: TCP
-      restartPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  ports:
-  - port: 80
-    protocol: TCP
-    targetPort: 80
-  selector:
-    app: hello-world
-```
-{{% /accordion %}}
+1. Copy the `hello-world` deployment manifest below.
+
+   <details id="hello-world">
+     <summary>Hello World Manifest</summary>
+
+     ```
+     apiVersion: apps/v1beta2
+     kind: Deployment
+     metadata:
+       labels:
+         app: hello-world
+       name: hello-world
+       namespace: default
+     spec:
+       replicas: 1
+       selector:
+         matchLabels:
+           app: hello-world
+       strategy:
+         rollingUpdate:
+           maxSurge: 1
+           maxUnavailable: 0
+         type: RollingUpdate
+       template:
+         metadata:
+           labels:
+             app: hello-world
+         spec:
+           containers:
+           - image: rancher/hello-world
+             imagePullPolicy: Always
+             name: hello-world
+             resources:
+               requests:
+                 cpu: 500m
+                 memory: 64Mi
+             ports:
+             - containerPort: 80
+               protocol: TCP
+           restartPolicy: Always
+     ---
+     apiVersion: v1
+     kind: Service
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       ports:
+       - port: 80
+         protocol: TCP
+         targetPort: 80
+       selector:
+         app: hello-world
+     ```
+
+</details>
 
 1. Deploy it to your cluster.
 
@@ -72,423 +76,457 @@ spec:
     ```
 
 1. Copy one of the HPAs below based on the metric type you're using:
-{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 1000Mi
-```
-{{% /accordion %}}
-{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 100Mi
-  - type: Pods
-    pods:
-      metricName: cpu_system
-      targetAverageValue: 20m
-```
-{{% /accordion %}}
+
+   <details id="service-deployment-resource-metrics">
+     <summary>Hello World HPA: Resource Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 1000Mi
+     ```
+
+   </details>
+   <details id="service-deployment-custom-metrics">
+     <summary>Hello World HPA: Custom Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 100Mi
+       - type: Pods
+         pods:
+           metricName: cpu_system
+           targetAverageValue: 20m
+     ```
+
+   </details>
 
 1. View the HPA info and description. Confirm that metric data is shown.
-    {{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
-1. Enter the following commands.
-    ```
-    # kubectl get hpa
-    NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
-    hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
-    # kubectl describe hpa
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             1253376 / 100Mi
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
-    {{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive the output that follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             3514368 / 100Mi
-      "cpu_system" on pods:                                0 / 20m
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
+
+   <details id="hpa-info-resource-metrics">
+     <summary>Resource Metrics</summary>
+
+     1. Enter the following commands.
+         ```
+         # kubectl get hpa
+         NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
+         hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
+         # kubectl describe hpa
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             1253376 / 100Mi
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+   </details>
+   <details id="hpa-info-custom-metrics">
+     <summary>Custom Metrics</summary>
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive the output that follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             3514368 / 100Mi
+           "cpu_system" on pods:                                0 / 20m
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
 
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
 1. Test that pod autoscaling works as intended.<br/><br/>
   **To Test Autoscaling Using Resource Metrics:**
-  {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. View your HPA.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive output similar to what follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             10928128 / 100Mi
-      resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-      ```
-1. Enter the following command to confirm you've scaled to two pods.
-   ```
-      # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-   ```
-  {{% /accordion %}}
-  {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
+   <details id="observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             9424896 / 100Mi
-        resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-    ```
-2. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-    You should receive output similar to what follows.
-     ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-      ```
-  {{% /accordion %}}
-  {{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+     Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             10070016 / 100Mi
-        resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-  ```
-  {{% /accordion %}}
-<br/>
-**To Test Autoscaling Using Custom Metrics:**
-  {{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale two pods based on CPU usage.
+     1. View your HPA.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive output similar to what follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             10928128 / 100Mi
+           resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+           ```
+     1. Enter the following command to confirm you've scaled to two pods.
+        ```
+           # kubectl get pods
+        ```
+        You should receive output similar to what follows:
+        ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+        ```
 
-1. Enter the following command.
-  ```
-    # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             8159232 / 100Mi
-      "cpu_system" on pods:                                7m / 20m
-      resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-  ```
-1. Enter the following command to confirm two pods are running.
-  ```
-    # kubectl get pods
-  ```
-  You should receive output similar to what follows.
-  ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-  ```
-  {{% /accordion %}}
-{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown">
+     <summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows:
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-    ```
-1. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      # kubectl get pods
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-   ```
-{{% /accordion %}}
-{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+     Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-        Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-    ```
-1.  Enter the following command to confirm four pods are running.
-    ```
-    # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
-{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
-
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive similar output to what follows.
-    ```
-        Name:                                                  hello-world
-        Namespace:                                             default
-        Labels:                                                <none>
-        Annotations:                                           <none>
-        CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-        Reference:                                             Deployment/hello-world
-        Metrics:                                               ( current / target )
-          resource memory on pods:                             8101888 / 100Mi
-          "cpu_system" on pods:                                8m / 20m
-          resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-        Min replicas:                                          1
-        Max replicas:                                          10
-        Conditions:
-          Type            Status  Reason              Message
-          ----            ------  ------              -------
-          AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-          ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-          ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-        Events:
-          Type    Reason             Age   From                       Message
-          ----    ------             ----  ----                       -------
-          Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-          Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-          Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-          Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-    ```
-1. Enter the following command to confirm a single pods is running.
-    ```
+     1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows
+        ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             9424896 / 100Mi
+             resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+         ```
+     2. Enter the following command to confirm three pods are running.
+        ```
         # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
+        ```
+         You should receive output similar to what follows.
+          ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+           ```
+
+   </details>
+   <details id="observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+
+     1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             10070016 / 100Mi
+             resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+       ```
+
+   </details>
+
+   **To Test Autoscaling Using Custom Metrics:**
+
+   <details id="custom-observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale two pods based on CPU usage.
+
+     1. Enter the following command.
+       ```
+         # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             8159232 / 100Mi
+           "cpu_system" on pods:                                7m / 20m
+           resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+       ```
+     1. Enter the following command to confirm two pods are running.
+       ```
+         # kubectl get pods
+       ```
+       You should receive output similar to what follows.
+       ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown-2">
+    <summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
+
+    Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+
+    1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows:
+       ```
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             8374272 / 100Mi
+            "cpu_system" on pods:                                27m / 20m
+            resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:
+            Type    Reason             Age   From                       Message
+            ----    ------             ----  ----                       -------
+            Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+        ```
+    1. Enter the following command to confirm three pods are running.
+       ```
+       # kubectl get pods
+       ```
+       You should receive output similar to what follows:
+       ```
+          # kubectl get pods
+          NAME                           READY     STATUS    RESTARTS   AGE
+          hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
+          hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+          hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-4-pods">
+    <summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
+
+    Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+
+    1. Enter the following command.
+      ```
+      # kubectl describe hpa
+      ```
+      You should receive output similar to what follows.
+      ```
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             8374272 / 100Mi
+            "cpu_system" on pods:                                27m / 20m
+            resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:
+            Type    Reason             Age   From                       Message
+            ----    ------             ----  ----                       -------
+            Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+            Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+        ```
+    1.  Enter the following command to confirm four pods are running.
+        ```
+        # kubectl get pods
+        ```
+        You should receive output similar to what follows.
+        ```
+          NAME                           READY     STATUS    RESTARTS   AGE
+          hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
+          hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
+          hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+          hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+        ```
+   </details>
+   <details id="custom-metrics-observe-downscale-1-pod">
+    <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+    Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
+
+    1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive similar output to what follows.
+        ```
+            Name:                                                  hello-world
+            Namespace:                                             default
+            Labels:                                                <none>
+            Annotations:                                           <none>
+            CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+            Reference:                                             Deployment/hello-world
+            Metrics:                                               ( current / target )
+              resource memory on pods:                             8101888 / 100Mi
+              "cpu_system" on pods:                                8m / 20m
+              resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+            Min replicas:                                          1
+            Max replicas:                                          10
+            Conditions:
+              Type            Status  Reason              Message
+              ----            ------  ------              -------
+              AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+              ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+              ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+            Events:
+              Type    Reason             Age   From                       Message
+              ----    ------             ----  ----                       -------
+              Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+              Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+              Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+              Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+        ```
+    1. Enter the following command to confirm a single pods is running.
+        ```
+            # kubectl get pods
+        ```
+        You should receive output similar to what follows.
+        ```
+            NAME                           READY     STATUS    RESTARTS   AGE
+            hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+        ```
+    </details>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/overview/overview.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/overview/overview.md
index 16d8a5d0590..d593b0ddf86 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/overview/overview.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/overview/overview.md
@@ -49,7 +49,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 ### Cluster Visibility
 
 - **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
-- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution. 
+- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
 - **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
 
 # Editing Downstream Clusters with Rancher
@@ -60,4 +60,4 @@ After a cluster is created with Rancher, a cluster administrator can manage clus
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table</summary>
diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.3/hardening-2.3.3/hardening-2.3.3.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.3/hardening-2.3.3/hardening-2.3.3.md
index bf75ee6a04e..cb7949895a4 100644
--- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.3/hardening-2.3.3/hardening-2.3.3.md
+++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/security/rancher-2.3.x/rancher-v2.3.3/hardening-2.3.3/hardening-2.3.3.md
@@ -172,7 +172,7 @@ etcd is a highly-available key-value store used by Kubernetes deployments for pe
 
 On a etcd server node, get the etcd data directory, passed as an argument `--data-dir`, from the below command:
 
-``` bash 
+``` bash
 ps -ef | grep etcd
 ```
 
@@ -1271,7 +1271,8 @@ runcmd:
 
 Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes.
 
-{{% accordion id="cluster-1.14" label="RKE yaml for k8s 1.14" %}}
+<details id="cluster-1.14">
+  <summary>RKE yaml for k8s 1.14</summary>
 
 ``` yaml
 nodes:
@@ -1295,48 +1296,48 @@ bastion_host:
   ssh_agent_auth: false
 cloud_provider: {}
 ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
 ingress:
   provider: nginx
 kubernetes_version: v1.14.9-rancher1-1
 monitoring:
   provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
 network:
   options:
     flannel_backend_type: vxlan
   plugin: canal
 restore:
   restore: false
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1346,7 +1347,7 @@ restore:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
 services:
   etcd:
     backup_config:
@@ -1401,9 +1402,10 @@ services:
 ssh_agent_auth: false
 ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="cluster-1.15" label="RKE yaml for k8s 1.15" %}}
+<details id="cluster-1.15">
+  <summary>RKE yaml for k8s 1.15</summary>
 
 ``` yaml
 nodes:
@@ -1423,46 +1425,46 @@ addon_job_timeout: 30
 authentication:
   strategy: x509
 ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
 ingress:
   provider: nginx
 kubernetes_version: v1.15.6-rancher1-2
 monitoring:
   provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
 network:
   options:
     flannel_backend_type: vxlan
   plugin: canal
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1472,7 +1474,7 @@ network:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
 services:
   etcd:
     backup_config:
@@ -1525,9 +1527,10 @@ services:
 ssh_agent_auth: false
 ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="cluster-1.16" label="RKE yaml for k8s 1.16" %}}
+<details id="cluster-1.16">
+  <summary>RKE yaml for k8s 1.16</summary>
 
 ``` yaml
 nodes:
@@ -1547,46 +1550,46 @@ addon_job_timeout: 30
 authentication:
   strategy: x509
 ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
 ingress:
   provider: nginx
 kubernetes_version: v1.16.3-rancher1-1
 monitoring:
   provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
 network:
   options:
     flannel_backend_type: vxlan
   plugin: canal
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1596,7 +1599,7 @@ network:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
 services:
   etcd:
     backup_config:
@@ -1649,19 +1652,20 @@ services:
 ssh_agent_auth: false
 ```
 
-{{% /accordion %}}
+</details>
 
 ## Appendix C - Complete RKE Template Example
 
-Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes. 
+Before apply, replace `rancher_kubernetes_engine_config.services.etcd.gid` and `rancher_kubernetes_engine_config.services.etcd.uid` with the proper etcd group and user ids that were created on etcd nodes.
 
 
-{{% accordion id="k8s-1.14" label="RKE template for k8s 1.14" %}}
+<details id="k8s-1.14">
+  <summary>RKE template for k8s 1.14</summary>
 
 ``` yaml
-# 
+#
 # Cluster Config
-# 
+#
 answers: {}
 default_pod_security_policy_template_id: restricted
 docker_root_dir: /var/lib/docker
@@ -1671,9 +1675,9 @@ enable_network_policy: false
 local_cluster_auth_endpoint:
   enabled: false
 name: test-35378
-# 
+#
 # Rancher Config
-# 
+#
 rancher_kubernetes_engine_config:
   addon_job_timeout: 30
   authentication:
@@ -1683,48 +1687,48 @@ rancher_kubernetes_engine_config:
     ssh_agent_auth: false
   cloud_provider: {}
   ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
   ingress:
     provider: nginx
   kubernetes_version: v1.14.9-rancher1-1
   monitoring:
     provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
   network:
     options:
       flannel_backend_type: vxlan
     plugin: canal
   restore:
     restore: false
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1734,7 +1738,7 @@ rancher_kubernetes_engine_config:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
   services:
     etcd:
       backup_config:
@@ -1790,14 +1794,15 @@ rancher_kubernetes_engine_config:
 windows_prefered_cluster: false
 ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="k8s-1.15" label="RKE template for k8s 1.15" %}}
+<details id="k8s-1.15">
+  <summary>RKE template for k8s 1.15</summary>
 
 ``` yaml
-# 
+#
 # Cluster Config
-# 
+#
 default_pod_security_policy_template_id: restricted
 docker_root_dir: /var/lib/docker
 enable_cluster_alerting: false
@@ -1805,54 +1810,54 @@ enable_cluster_monitoring: false
 enable_network_policy: false
 local_cluster_auth_endpoint:
   enabled: true
-# 
+#
 # Rancher Config
-# 
+#
 rancher_kubernetes_engine_config:
   addon_job_timeout: 30
   authentication:
     strategy: x509
   ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
   ingress:
     provider: nginx
   kubernetes_version: v1.15.6-rancher1-2
   monitoring:
     provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
   network:
     options:
       flannel_backend_type: vxlan
     plugin: canal
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1862,7 +1867,7 @@ rancher_kubernetes_engine_config:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
   services:
     etcd:
       backup_config:
@@ -1916,14 +1921,15 @@ rancher_kubernetes_engine_config:
 windows_prefered_cluster: false
 ```
 
-{{% /accordion %}}
+</details>
 
-{{% accordion id="k8s-1.16" label="RKE template for k8s 1.16" %}}
+<details id="k8s-1.16">
+  <summary>RKE template for k8s 1.16</summary>
 
 ``` yaml
-# 
+#
 # Cluster Config
-# 
+#
 default_pod_security_policy_template_id: restricted
 docker_root_dir: /var/lib/docker
 enable_cluster_alerting: false
@@ -1931,54 +1937,54 @@ enable_cluster_monitoring: false
 enable_network_policy: false
 local_cluster_auth_endpoint:
   enabled: true
-# 
+#
 # Rancher Config
-# 
+#
 rancher_kubernetes_engine_config:
   addon_job_timeout: 30
   authentication:
     strategy: x509
   ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
   ingress:
     provider: nginx
   kubernetes_version: v1.16.3-rancher1-1
   monitoring:
     provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
   network:
     options:
       flannel_backend_type: vxlan
     plugin: canal
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -1988,7 +1994,7 @@ rancher_kubernetes_engine_config:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
   services:
     etcd:
       backup_config:
@@ -2042,4 +2048,4 @@ rancher_kubernetes_engine_config:
 windows_prefered_cluster: false
 ```
 
-{{% /accordion %}}
+</details>
diff --git a/versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md b/versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
index 2e55f3cadc6..223932f203b 100644
--- a/versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
+++ b/versioned_docs/version-2.5/v2.5/en/admin-settings/rbac/cluster-project-roles/cluster-project-roles.md
@@ -165,14 +165,21 @@ You can change the cluster or project role(s) that are automatically assigned to
 1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **&#8942; > Edit**.
 
 1. Enable the role as default.
-{{% accordion id="cluster" label="For Clusters" %}}
+
+<details id="cluster">
+  <summary>For Clusters</summary>
+
 1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
 1. Click **Save**.
-{{% /accordion %}}
-{{% accordion id="project" label="For Projects" %}}
+
+</details>
+<details id="project">
+
+  <summary>For Projects</summary>
 1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
 1. Click **Save**.
-{{% /accordion %}}
+
+</details>
 
 1. If you want to remove a default role, edit the permission and select **No** from the default roles option.
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-admin.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-admin.md
index 26a02781cbb..1feabb90c15 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-admin.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/cluster-admin.md
@@ -23,9 +23,9 @@ Alternatively, you can switch between projects and clusters directly in the navi
 
 ## Managing Clusters in Rancher
 
-After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster. 
+After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
 
-{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 ## Configuring Tools
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/editing-clusters.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/editing-clusters.md
index e98acf0367d..6e8fcc2906c 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/editing-clusters.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/editing-clusters.md
@@ -24,5 +24,5 @@ The options and settings available for an existing cluster change based on the m
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
index fae6dfb5e29..fd1ee175704 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/eks-config-reference.md
@@ -341,7 +341,8 @@ Option | Description
 
 If you choose to assign a public IP address to your cluster's worker nodes, you have the option of choosing between a VPC that's automatically generated by Rancher (i.e., **Standard: Rancher generated VPC and Subnet**), or a VPC that you've already created with AWS (i.e., **Custom: Choose from your existing VPC and Subnets**). Choose the option that best fits your use case.
 
-{{% accordion id="yes" label="Click to expand" %}}
+<details id="yes">
+  <summary>Click to expand</summary>
 
 If you're using **Custom: Choose from your existing VPC and Subnets**:
 
@@ -354,10 +355,13 @@ If you're using **Custom: Choose from your existing VPC and Subnets**:
 1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
 
 1. Click **Next: Select Security Group**.
-{{% /accordion %}}
+</details>
 
 If your worker nodes have Private IPs only, you must also choose a **VPC & Subnet** that allow your instances to access the internet. This access is required so that your worker nodes can connect to the Kubernetes control plane.
-{{% accordion id="no" label="Click to expand" %}}
+
+<details id="no">
+  <summary>Click to expand</summary>
+
 Follow the steps below.
 
 >**Tip:** When using only private IP addresses, you can provide your nodes internet access by creating a VPC constructed with two subnets, a private set and a public set.  The private set should have its route tables configured to point toward a NAT in the public set.  For more information on routing traffic from private subnets, please see the [official AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html).
@@ -366,7 +370,7 @@ Follow the steps below.
 
 1. Click **Next: Select Subnets**. Then choose one of the **Subnets** that displays.
 
-{{% /accordion %}}
+</details>
 
 ### Security Group
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-provisioning.md b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-provisioning.md
index 8fe1bc1c856..e1d203eec2f 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-provisioning.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/cluster-provisioning.md
@@ -32,7 +32,7 @@ This section covers the following topics:
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 # Setting up Clusters in a Hosted Kubernetes Provider
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
index 0e9498bc520..66e1ae08b16 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
 
 If you want to use the Azure CLI, you can run the command `az account show` to get the information.
 
-### 2. Set up the Azure Client ID and Azure Client Secret 
+### 2. Set up the Azure Client ID and Azure Client Secret
 
 Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
 
diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md
index 9285d589396..256226b93a7 100644
--- a/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md
+++ b/versioned_docs/version-2.5/v2.5/en/cluster-provisioning/rke-clusters/options/options.md
@@ -177,7 +177,8 @@ Instead of using the Rancher UI to choose Kubernetes options for the cluster, ad
 
 RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
 
-{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
+<details id="v2.3.0-cluster-config-file">
+  <summary>Example Cluster Config File</summary>
 
 ```yaml
 #
@@ -269,7 +270,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
   ssh_agent_auth: false
 windows_prefered_cluster: false
 ```
-{{% /accordion %}}
+</details>
 
 ### Default DNS provider
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md b/versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
index 70bb0f8565f..c46829dc0de 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
@@ -120,7 +120,8 @@ There are three recommended options for the source of the certificate used for T
 
 This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
 
-{{% accordion id="cert-manager" label="Click to Expand" %}}
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
 
 > **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.5/en/installation/options/upgrading-cert-manager/).
 
@@ -154,7 +155,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
 cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
 ```
 
-{{% /accordion %}}
+</details>
 
 ### 5. Install Rancher with Helm and Your Chosen Certificate Option
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
index 81a30b69e84..2e4fdf50ca2 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
@@ -3,9 +3,9 @@ title: Docker Install Commands
 weight: 1
 ---
 
-The Docker installation is for Rancher users who want to test out Rancher. 
+The Docker installation is for Rancher users who want to test out Rancher.
 
-Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. 
+Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
 
 For Rancher v2.5+, the backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
 
@@ -25,7 +25,8 @@ Choose from the following options:
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
 
@@ -47,11 +48,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
 
@@ -86,11 +88,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
 
@@ -122,7 +125,7 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index 98c4312d0f9..81b0c047045 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -272,7 +272,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
 
 ### For Self-Signed Certificate Installs, Install Cert-manager
 
-{{% accordion id="install-cert-manager" label="Click to expand" %}}
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
 
 If you are using self-signed certificates, install cert-manager:
 
@@ -294,7 +295,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
 kubectl apply -R -f ./cert-manager
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Install Rancher with kubectl
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index b8f35c99dd2..36243f8cab5 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -141,7 +141,8 @@ Select which option you had installed Rancher server
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -159,11 +160,12 @@ docker run -d --volumes-from rancher-data \
 
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -190,11 +192,12 @@ docker run -d --volumes-from rancher-data \
 
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
 
@@ -219,11 +222,12 @@ docker run -d --volumes-from rancher-data \
 ```
 
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
-{{% /accordion %}}
+</details>
 
 ### Option D: Let's Encrypt Certificate
 
-{{% accordion id="option-d" label="Click to expand" %}}
+<details id="option-d">
+  <summary>Click to expand</summary>
 
 >**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
 
@@ -250,7 +254,7 @@ docker run -d --volumes-from rancher-data \
 
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 <TabItem value="Docker Air Gap Upgrade">
@@ -261,7 +265,8 @@ When starting the new Rancher server container, choose from the following option
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -281,11 +286,12 @@ Placeholder | Description
 ```
 
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -312,11 +318,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
 
@@ -345,7 +352,7 @@ docker run -d --volumes-from rancher-data \
      <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher-v2-5)
-{{% /accordion %}}
+</details>
 
 </TabItem>
 </Tabs>
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md b/versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md
index 4835802f491..50c1acbe8a2 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/requirements/ports/ports.md
@@ -43,7 +43,8 @@ As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster. For Ranc
 
 ### Ports for Rancher Server Nodes on K3s
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The K3s server needs port 6443 to be accessible by the nodes.
 
@@ -74,11 +75,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP      | 2376 | Any node IP from a node created using Node driver        | Docker daemon TLS port used by Docker Machine |
 | TCP      | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
 
@@ -118,13 +120,14 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 | TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RancherD or RKE2
 
 > **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The RancherD (or RKE2) server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
 
@@ -149,11 +152,12 @@ If you wish to utilize the metrics server, you will need to open port 10250 on e
 | HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
 
 Typically all outbound traffic is allowed.
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server in Docker
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
 
@@ -173,7 +177,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
 | TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
 | TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
 
-{{% /accordion %}}
+</details>
 
 # Downstream Kubernetes Cluster Nodes
 
@@ -193,7 +197,8 @@ The following diagram depicts the ports that are opened for each [cluster type](
 
 ### Ports for Rancher Launched Kubernetes Clusters using Node Pools
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/).
 
@@ -202,39 +207,42 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
 
 {{< ports-iaas-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes/).
 
 {{< ports-custom-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Hosted Kubernetes Clusters
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Registered Clusters
 
 Note: Registered clusters were called imported clusters before Rancher v2.5.
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [registered clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 
 # Other Port Considerations
@@ -243,7 +251,7 @@ The following table depicts the port requirements for [registered clusters]({{<b
 
 These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
 
-{{% include file="/rancher/v2.5/en/installation/requirements/ports/common-ports-table" %}}
+{{% include file="/rancher/v2.5/en/installation/requirements/ports/common-ports-table</summary>
 
 ----
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md b/versioned_docs/version-2.5/v2.5/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
index aba571407bd..5654ae5e26e 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
@@ -49,7 +49,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
+
 If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
 
 > **Prerequisites:**
@@ -68,8 +70,10 @@ If you elect to use a self-signed certificate to encrypt communication, you must
      rancher/rancher:latest
    ```
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
+
 If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
 
 > **Prerequisites:**
@@ -88,7 +92,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
         rancher/rancher:latest --no-cacerts
         ```
 
-    {{% /accordion %}}
+</details>
 
 ## 3. Configure Load Balancer
 
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md b/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
index 070dff28f02..c7c55b8a4db 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/helm-2-instructions/helm-2-instructions.md
@@ -22,22 +22,24 @@ To address these changes, this guide will do two things:
 
 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
-> 3. Install the newer version of Rancher and cert-manager 
+> 3. Install the newer version of Rancher and cert-manager
 
 > The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
 
-> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section. 
+> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
 
-## Upgrade Cert-Manager Only 
+## Upgrade Cert-Manager Only
 
 > **Note:**
-> These instructions are applied if you have no plan to upgrade Rancher. 
+> These instructions are applied if you have no plan to upgrade Rancher.
 
 The namespace used in these instructions depends on the namespace cert-manager is currently installed in. If it is in kube-system use that in the instructions below. You can verify by running `kubectl get pods --all-namespaces` and checking which namespace the cert-manager-\* pods are listed in. Do not change the namespace cert-manager is running in or this can cause issues.
 
 In order to upgrade cert-manager, follow these instructions:
 
-{{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}}
+<details id="normal">
+  <summary>Upgrading cert-manager with Internet access</summary>
+
 1. Back up existing resources as a precaution
 
     ```plain
@@ -73,9 +75,11 @@ In order to upgrade cert-manager, follow these instructions:
     ```plain
     helm install --version 0.12.0 --name cert-manager --namespace kube-system jetstack/cert-manager
     ```
-{{% /accordion %}}
+</details>
+
+<details id="airgap">
+  <summary>Upgrading cert-manager in an airgapped environment</summary>
 
-{{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}}
 ### Prerequisites
 
 Before you can perform the upgrade, you must prepare your air gapped environment by adding the necessary container images to your private registry and downloading or rendering the required Kubernetes manifest files.
@@ -137,7 +141,7 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     ```plain
     kubectl -n kube-system apply -R -f ./cert-manager
     ```
-{{% /accordion %}}
+</details>
 
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
diff --git a/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md b/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
index 9b557f0ccc7..2a40ea052ab 100644
--- a/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+++ b/versioned_docs/version-2.5/v2.5/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
@@ -24,11 +24,11 @@ To address these changes, this guide will do two things:
 
 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
-> 3. Install the newer version of Rancher and cert-manager 
+> 3. Install the newer version of Rancher and cert-manager
 
 > The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
 
-> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section. 
+> For reinstalling Rancher with Helm, please check [Option B: Reinstalling Rancher Chart]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/) under the upgrade Rancher section.
 
 # Upgrade Cert-Manager
 
@@ -40,7 +40,9 @@ In order to upgrade cert-manager, follow these instructions:
 
 ### Option A: Upgrade cert-manager with Internet Access
 
-{{% accordion id="normal" label="Click to expand" %}}
+<details id="normal">
+  <summary>Click to expand</summary>
+
 1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
 
     ```plain
@@ -96,7 +98,7 @@ In order to upgrade cert-manager, follow these instructions:
     helm install \
       cert-manager jetstack/cert-manager \
       --namespace cert-manager \
-      --version v0.12.0 
+      --version v0.12.0
     ```
 
 1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -105,11 +107,12 @@ In order to upgrade cert-manager, follow these instructions:
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Upgrade cert-manager in an Air Gap Environment
 
-{{% accordion id="airgap" label="Click to expand" %}}
+<details id="airgap">
+  <summary>Click to expand</summary>
 
 ### Prerequisites
 
@@ -212,9 +215,9 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
-### Verify the Deployment 
+### Verify the Deployment
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
 
diff --git a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
index d1e3900f3e5..3488e61a160 100644
--- a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+++ b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
@@ -161,7 +161,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
     ```
     Then review the log output to confirm the service is running.
-    {{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
+
+    <details id="prometheus-logs">
+      <summary>Prometheus Adaptor Logs</summary>
+
     ...
     I0724 10:18:45.696679       1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
     I0724 10:18:45.696695       1 round_trippers.go:442] Response Headers:
@@ -174,7 +177,7 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     I0724 10:18:45.699939       1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
     I0724 10:18:51.727845       1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
     ...
-    {{% /accordion %}}
+    </details>
 
 
 
@@ -185,15 +188,21 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response" label="API Response" %}}
+
+    <details id="custom-metrics-api-response">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
 
   - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
     ```
     # kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
+
+    <details id="custom-metrics-api-response-rancher">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+    </details>
diff --git a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
index 5f4a16b0367..2169b69812e 100644
--- a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -12,58 +12,62 @@ For HPA to work correctly, service deployments should have resources request def
 
 1. Configure `kubectl` to connect to your Kubernetes cluster.
 
-2. Copy the `hello-world` deployment manifest below.
-{{% accordion id="hello-world" label="Hello World Manifest" %}}
-```
-apiVersion: apps/v1beta2
-kind: Deployment
-metadata:
-  labels:
-    app: hello-world
-  name: hello-world
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: hello-world
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
-    type: RollingUpdate
-  template:
-    metadata:
-      labels:
-        app: hello-world
-    spec:
-      containers:
-      - image: rancher/hello-world
-        imagePullPolicy: Always
-        name: hello-world
-        resources:
-          requests:
-            cpu: 500m
-            memory: 64Mi
-        ports:
-        - containerPort: 80
-          protocol: TCP
-      restartPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  ports:
-  - port: 80
-    protocol: TCP
-    targetPort: 80
-  selector:
-    app: hello-world
-```
-{{% /accordion %}}
+1. Copy the `hello-world` deployment manifest below.
+
+   <details id="hello-world">
+     <summary>Hello World Manifest</summary>
+
+     ```
+     apiVersion: apps/v1beta2
+     kind: Deployment
+     metadata:
+       labels:
+         app: hello-world
+       name: hello-world
+       namespace: default
+     spec:
+       replicas: 1
+       selector:
+         matchLabels:
+           app: hello-world
+       strategy:
+         rollingUpdate:
+           maxSurge: 1
+           maxUnavailable: 0
+         type: RollingUpdate
+       template:
+         metadata:
+           labels:
+             app: hello-world
+         spec:
+           containers:
+           - image: rancher/hello-world
+             imagePullPolicy: Always
+             name: hello-world
+             resources:
+               requests:
+                 cpu: 500m
+                 memory: 64Mi
+             ports:
+             - containerPort: 80
+               protocol: TCP
+           restartPolicy: Always
+     ---
+     apiVersion: v1
+     kind: Service
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       ports:
+       - port: 80
+         protocol: TCP
+         targetPort: 80
+       selector:
+         app: hello-world
+     ```
+
+</details>
 
 1. Deploy it to your cluster.
 
@@ -72,423 +76,459 @@ spec:
     ```
 
 1. Copy one of the HPAs below based on the metric type you're using:
-{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 1000Mi
-```
-{{% /accordion %}}
-{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 100Mi
-  - type: Pods
-    pods:
-      metricName: cpu_system
-      targetAverageValue: 20m
-```
-{{% /accordion %}}
+
+   <details id="service-deployment-resource-metrics">
+     <summary>Hello World HPA: Resource Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 1000Mi
+     ```
+
+   </details>
+   <details id="service-deployment-custom-metrics">
+     <summary>Hello World HPA: Custom Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 100Mi
+       - type: Pods
+         pods:
+           metricName: cpu_system
+           targetAverageValue: 20m
+     ```
+
+   </details>
 
 1. View the HPA info and description. Confirm that metric data is shown.
-    {{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
-1. Enter the following commands.
-    ```
-    # kubectl get hpa
-    NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
-    hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
-    # kubectl describe hpa
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             1253376 / 100Mi
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
-    {{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive the output that follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             3514368 / 100Mi
-      "cpu_system" on pods:                                0 / 20m
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
 
+   <details id="hpa-info-resource-metrics">
+     <summary>Resource Metrics</summary>
+
+     1. Enter the following commands.
+         ```
+         # kubectl get hpa
+         NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
+         hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
+         # kubectl describe hpa
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             1253376 / 100Mi
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
+   <details id="hpa-info-custom-metrics">
+     <summary>Custom Metrics</summary>
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive the output that follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             3514368 / 100Mi
+           "cpu_system" on pods:                                0 / 20m
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
 1. Test that pod autoscaling works as intended.<br/><br/>
   **To Test Autoscaling Using Resource Metrics:**
-  {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. View your HPA.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive output similar to what follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             10928128 / 100Mi
-      resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-      ```
-1. Enter the following command to confirm you've scaled to two pods.
-   ```
-      # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-   ```
-  {{% /accordion %}}
-  {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
+   <details id="observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             9424896 / 100Mi
-        resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-    ```
-2. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-    You should receive output similar to what follows.
-     ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-      ```
-  {{% /accordion %}}
-  {{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+     Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             10070016 / 100Mi
-        resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-  ```
-  {{% /accordion %}}
-<br/>
-**To Test Autoscaling Using Custom Metrics:**
-  {{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale two pods based on CPU usage.
+     1. View your HPA.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive output similar to what follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             10928128 / 100Mi
+           resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+           ```
+     1. Enter the following command to confirm you've scaled to two pods.
+        ```
+           # kubectl get pods
+        ```
+        You should receive output similar to what follows:
+        ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+        ```
 
-1. Enter the following command.
-  ```
-    # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             8159232 / 100Mi
-      "cpu_system" on pods:                                7m / 20m
-      resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-  ```
-1. Enter the following command to confirm two pods are running.
-  ```
-    # kubectl get pods
-  ```
-  You should receive output similar to what follows.
-  ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-  ```
-  {{% /accordion %}}
-{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown">
+     <summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows:
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-    ```
-1. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      # kubectl get pods
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-   ```
-{{% /accordion %}}
-{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+     Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-        Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-    ```
-1.  Enter the following command to confirm four pods are running.
-    ```
-    # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
-{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
-
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive similar output to what follows.
-    ```
-        Name:                                                  hello-world
-        Namespace:                                             default
-        Labels:                                                <none>
-        Annotations:                                           <none>
-        CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-        Reference:                                             Deployment/hello-world
-        Metrics:                                               ( current / target )
-          resource memory on pods:                             8101888 / 100Mi
-          "cpu_system" on pods:                                8m / 20m
-          resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-        Min replicas:                                          1
-        Max replicas:                                          10
-        Conditions:
-          Type            Status  Reason              Message
-          ----            ------  ------              -------
-          AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-          ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-          ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-        Events:
-          Type    Reason             Age   From                       Message
-          ----    ------             ----  ----                       -------
-          Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-          Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-          Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-          Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-    ```
-1. Enter the following command to confirm a single pods is running.
-    ```
+     1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows
+        ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             9424896 / 100Mi
+             resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+         ```
+     2. Enter the following command to confirm three pods are running.
+        ```
         # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
+        ```
+         You should receive output similar to what follows.
+          ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+           ```
+
+   </details>
+   <details id="observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+
+     1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             10070016 / 100Mi
+             resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+       ```
+
+   </details>
+
+   **To Test Autoscaling Using Custom Metrics:**
+
+   <details id="custom-observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale two pods based on CPU usage.
+
+     1. Enter the following command.
+       ```
+         # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             8159232 / 100Mi
+           "cpu_system" on pods:                                7m / 20m
+           resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+       ```
+     1. Enter the following command to confirm two pods are running.
+       ```
+         # kubectl get pods
+       ```
+       You should receive output similar to what follows.
+       ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown-2">
+     <summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+
+     1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows:
+        ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             8374272 / 100Mi
+             "cpu_system" on pods:                                27m / 20m
+             resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+         ```
+     1. Enter the following command to confirm three pods are running.
+        ```
+        # kubectl get pods
+        ```
+        You should receive output similar to what follows:
+        ```
+           # kubectl get pods
+           NAME                           READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
+           hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+           hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+        ```
+
+   </details>
+   <details id="observe-upscale-4-pods">
+     <summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+
+     1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             8374272 / 100Mi
+             "cpu_system" on pods:                                27m / 20m
+             resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+             Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+         ```
+     1.  Enter the following command to confirm four pods are running.
+         ```
+         # kubectl get pods
+         ```
+         You should receive output similar to what follows.
+         ```
+           NAME                           READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
+           hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
+           hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+           hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+         ```
+
+   </details>
+   <details id="custom-metrics-observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive similar output to what follows.
+         ```
+             Name:                                                  hello-world
+             Namespace:                                             default
+             Labels:                                                <none>
+             Annotations:                                           <none>
+             CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+             Reference:                                             Deployment/hello-world
+             Metrics:                                               ( current / target )
+               resource memory on pods:                             8101888 / 100Mi
+               "cpu_system" on pods:                                8m / 20m
+               resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+             Min replicas:                                          1
+             Max replicas:                                          10
+             Conditions:
+               Type            Status  Reason              Message
+               ----            ------  ------              -------
+               AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+               ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+               ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+             Events:
+               Type    Reason             Age   From                       Message
+               ----    ------             ----  ----                       -------
+               Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+               Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+               Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+               Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+         ```
+     1. Enter the following command to confirm a single pods is running.
+         ```
+             # kubectl get pods
+         ```
+         You should receive output similar to what follows.
+         ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+         ```
+
+   </details>
diff --git a/versioned_docs/version-2.5/v2.5/en/overview/overview.md b/versioned_docs/version-2.5/v2.5/en/overview/overview.md
index 0bfde58d339..5b81bbb90d4 100644
--- a/versioned_docs/version-2.5/v2.5/en/overview/overview.md
+++ b/versioned_docs/version-2.5/v2.5/en/overview/overview.md
@@ -51,7 +51,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 ### Cluster Visibility
 
 - **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
-- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution. 
+- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
 - **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
 
 # Editing Downstream Clusters with Rancher
@@ -62,4 +62,4 @@ After a cluster is created with Rancher, a cluster administrator can manage clus
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.5/en/cluster-provisioning/cluster-capabilities-table</summary>
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-admin.md b/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-admin.md
index 7919b01b210..386d4ab749a 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-admin.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-admin/cluster-admin.md
@@ -15,9 +15,9 @@ This page covers the following topics:
 
 ## Managing Clusters in Rancher
 
-After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster. 
+After clusters have been [provisioned into Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/), [cluster owners]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) will need to manage these clusters. There are many different options of how to manage your cluster.
 
-{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 ## Configuring Tools
 
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/editing-clusters.md b/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/editing-clusters.md
index cab7cdd0d06..5353fb6ef83 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/editing-clusters.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/editing-clusters.md
@@ -24,5 +24,5 @@ The options and settings available for an existing cluster change based on the m
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
 
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-reference.md b/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-reference.md
index 27e73a4c408..4c553c29959 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-reference.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/rke-config-reference.md
@@ -79,7 +79,7 @@ To edit an RKE config file directly from the Rancher UI,
 
 > Some advanced configuration options are not exposed in the Rancher UI forms, but they can be enabled by editing the RKE cluster configuration file in YAML. For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.]({{<baseurl>}}/rke/latest/en/config-options/)
 
-### Kubernetes Version 
+### Kubernetes Version
 
 The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
 
@@ -104,7 +104,7 @@ When Weave is selected as network provider, Rancher will automatically enable en
 
 ### Project Network Isolation
 
-If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication. 
+If your network provider allows project network isolation, you can choose whether to enable or disable inter-project communication.
 
 Project network isolation is available if you are using any RKE network plugin that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin.
 
@@ -127,7 +127,7 @@ The private registry configuration option tells Rancher where to pull the [syste
 - **System images** are components needed to maintain the Kubernetes cluster.
 - **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server.
 
-For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/). 
+For more information on setting up a private registry for components applied during the provisioning of the cluster, see the [RKE documentation on private registries]({{<baseurl>}}/rke/latest/en/config-options/private-registries/).
 
 Rancher v2.6 introduced the ability to configure [ECR registries for RKE clusters]({{<baseurl>}}/rke/latest/en/config-options/private-registries/#amazon-elastic-container-registry-ecr-private-registry-setup).
 
@@ -151,7 +151,7 @@ For information on using the Rancher UI to set up node pools in an RKE cluster,
 
 If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster.
 
-### Metrics Server Monitoring 
+### Metrics Server Monitoring
 
 Option to enable or disable [Metrics Server]({{<baseurl>}}/rke/latest/en/config-options/add-ons/metrics-server/).
 
@@ -165,7 +165,7 @@ You must have an existing Pod Security Policy configured before you can use this
 
 ### Docker Version on Nodes
 
-Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. 
+Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support.
 
 If you choose to require a supported Docker version, Rancher will stop pods from running on nodes that don't have a supported Docker version installed.
 
@@ -209,7 +209,8 @@ For the complete reference for configurable options for RKE Kubernetes clusters
 
 RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kubernetes clusters. Rancher's cluster config files used to have the same structure as [RKE config files,]({{<baseurl>}}/rke/latest/en/example-yamls/) but the structure changed so that in Rancher, RKE cluster config items are separated from non-RKE config items. Therefore, configuration for your cluster needs to be nested under the `rancher_kubernetes_engine_config` directive in the cluster config file. Cluster config files created with earlier versions of Rancher will need to be updated for this format. An example cluster config file is included below.
 
-{{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File" %}}
+<details id="v2.3.0-cluster-config-file">
+  <summary>Example Cluster Config File</summary>
 
 ```yaml
 #
@@ -301,7 +302,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
   ssh_agent_auth: false
 windows_prefered_cluster: false
 ```
-{{% /accordion %}}
+</details>
 
 ### Default DNS provider
 
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/cluster-provisioning.md b/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/cluster-provisioning.md
index 9e9f44c4c87..c5ced18401b 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/cluster-provisioning.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/cluster-provisioning.md
@@ -28,7 +28,7 @@ This section covers the following topics:
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
 
 # Setting up Clusters in a Hosted Kubernetes Provider
 
diff --git a/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md b/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
index 3bd7d676fd8..a6e80db75db 100644
--- a/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
+++ b/versioned_docs/version-2.6/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/azure/azure.md
@@ -31,7 +31,7 @@ Visit [Azure portal](https://portal.azure.com), login and go to **Azure Active D
 
 If you want to use the Azure CLI, you can run the command `az account show` to get the information.
 
-### 2. Set up the Azure Client ID and Azure Client Secret 
+### 2. Set up the Azure Client ID and Azure Client Secret
 
 Visit [Azure portal](https://portal.azure.com), login and follow the steps below to create an **App Registration** and the corresponding **Azure Client ID** (aadClientId) and **Azure Client Secret** (aadClientSecret).
 
@@ -75,36 +75,38 @@ Only hosts expected to be load balancer back ends need to be in this group.
 
 1. Choose "Azure" from the Cloud Provider drop-down in the Cluster Configuration section.
 
-1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. 
+1. * Supply the Cloud Provider Configuration. Note that Rancher will automatically create a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster.
    * You can click on "Show Advanced" to see more of these automatically generated names and update them if
-   necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group. 
+   necessary. Your Cloud Provider Configuration **must** match the fields in the Machine Pools section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
    * An example is provided below. You will modify it as needed.
 
-    {{% accordion id="v2.6.0-cloud-provider-config-file" label="Example Cloud Provider Config" %}}
+    <details id="v2.6.0-cloud-provider-config-file">
+      <summary>Example Cloud Provider Config</summary>
+
+    ```yaml
+    {
+        "cloud":"AzurePublicCloud",
+        "tenantId": "YOUR TENANTID HERE",
+        "aadClientId": "YOUR AADCLIENTID HERE",
+        "aadClientSecret": "YOUR AADCLIENTSECRET HERE",
+        "subscriptionId": "YOUR SUBSCRIPTIONID HERE",
+        "resourceGroup": "docker-machine",
+        "location": "westus",
+        "subnetName": "docker-machine",
+        "securityGroupName": "rancher-managed-KA4jV9V2",
+        "securityGroupResourceGroup": "docker-machine",
+        "vnetName": "docker-machine-vnet",
+        "vnetResourceGroup": "docker-machine",
+        "primaryAvailabilitySetName": "docker-machine",
+        "routeTableResourceGroup": "docker-machine",
+        "cloudProviderBackoff": false,
+        "useManagedIdentityExtension": false,
+        "useInstanceMetadata": true
+    }
+    ```
+
+    </details>
 
-```yaml
-{   
-    "cloud":"AzurePublicCloud",
-    "tenantId": "YOUR TENANTID HERE",
-    "aadClientId": "YOUR AADCLIENTID HERE",
-    "aadClientSecret": "YOUR AADCLIENTSECRET HERE",
-    "subscriptionId": "YOUR SUBSCRIPTIONID HERE",
-    "resourceGroup": "docker-machine",
-    "location": "westus",
-    "subnetName": "docker-machine",
-    "securityGroupName": "rancher-managed-KA4jV9V2",
-    "securityGroupResourceGroup": "docker-machine",
-    "vnetName": "docker-machine-vnet",
-    "vnetResourceGroup": "docker-machine",
-    "primaryAvailabilitySetName": "docker-machine",
-    "routeTableResourceGroup": "docker-machine",
-    "cloudProviderBackoff": false,
-    "useManagedIdentityExtension": false,
-    "useInstanceMetadata": true
-}
-```
-    {{% /accordion %}}
-    
 1. Under the **Cluster Configuration > Advanced** section, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`
 
 1. Click the **Create** button to submit the form and create the cluster.
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md b/versioned_docs/version-2.6/v2.6/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
index a9ae6557a37..d16d51e6555 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/install-rancher-on-k8s/install-rancher-on-k8s.md
@@ -113,7 +113,8 @@ There are three recommended options for the source of the certificate used for T
 
 This step is only required to use certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) or to request Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`).
 
-{{% accordion id="cert-manager" label="Click to Expand" %}}
+<details id="cert-manager">
+  <summary>Click to Expand</summary>
 
 > **Important:** Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{<baseurl>}}/rancher/v2.6/en/installation/resources/upgrading-cert-manager/).
 
@@ -147,7 +148,7 @@ cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
 cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
 ```
 
-{{% /accordion %}}
+</details>
 
 ### 5. Install Rancher with Helm and Your Chosen Certificate Option
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
index 97aeffdccaa..8c065fb3db3 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/docker-install-commands/docker-install-commands.md
@@ -3,9 +3,9 @@ title: Docker Install Commands
 weight: 1
 ---
 
-The Docker installation is for Rancher users who want to test out Rancher. 
+The Docker installation is for Rancher users who want to test out Rancher.
 
-Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. 
+Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
 
 The backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
 
@@ -25,7 +25,8 @@ Choose from the following options:
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself.
 
@@ -47,11 +48,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
 
@@ -86,11 +88,12 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 In development or testing environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings.
 
@@ -122,7 +125,7 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 
-{{% /accordion %}}
+</details>
 
 
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
index b5025c8c730..6ee7535d612 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md
@@ -201,7 +201,8 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati
 
 ### For Self-Signed Certificate Installs, Install Cert-manager
 
-{{% accordion id="install-cert-manager" label="Click to expand" %}}
+<details id="install-cert-manager">
+  <summary>Click to expand</summary>
 
 If you are using self-signed certificates, install cert-manager:
 
@@ -223,7 +224,7 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml
 kubectl apply -R -f ./cert-manager
 ```
 
-{{% /accordion %}}
+</details>
 
 ### Install Rancher with kubectl
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
index 96a881dcaa6..dcd9d02587b 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/single-node-upgrades.md
@@ -136,7 +136,8 @@ Select which option you had installed Rancher server
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -154,11 +155,12 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -185,11 +187,12 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
 
@@ -214,11 +217,12 @@ docker run -d --volumes-from rancher-data \
 ```
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+</details>
 
 ### Option D: Let's Encrypt Certificate
 
-{{% accordion id="option-d" label="Click to expand" %}}
+<details id="option-d">
+  <summary>Click to expand</summary>
 
 >**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
 
@@ -245,7 +249,7 @@ docker run -d --volumes-from rancher-data \
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
 
-{{% /accordion %}}
+</details>
 
 </TabItem>
 <TabItem value="Docker Air Gap Upgrade">
@@ -256,7 +260,8 @@ When starting the new Rancher server container, choose from the following option
 
 ### Option A: Default Self-Signed Certificate
 
-{{% accordion id="option-a" label="Click to expand" %}}
+<details id="option-a">
+  <summary>Click to expand</summary>
 
 If you have selected to use the Rancher generated self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container.
 
@@ -276,11 +281,13 @@ Placeholder | Description
 ```
 
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+
+</details>
 
 ### Option B: Bring Your Own Certificate: Self-Signed
 
-{{% accordion id="option-b" label="Click to expand" %}}
+<details id="option-b">
+  <summary>Click to expand</summary>
 
 If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
 
@@ -307,11 +314,13 @@ docker run -d --restart=unless-stopped \
     <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+
+</details>
 
 ### Option C: Bring Your Own Certificate: Signed by Recognized CA
 
-{{% accordion id="option-c" label="Click to expand" %}}
+<details id="option-c">
+  <summary>Click to expand</summary>
 
 If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
 
@@ -340,7 +349,8 @@ docker run -d --volumes-from rancher-data \
      <REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
 ```
 privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
-{{% /accordion %}}
+
+</details>
 
 </TabItem>
 </Tabs>
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/requirements/ports/ports.md b/versioned_docs/version-2.6/v2.6/en/installation/requirements/ports/ports.md
index 9365e00961c..ffe9e43eb48 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/requirements/ports/ports.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/requirements/ports/ports.md
@@ -42,7 +42,8 @@ Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3
 
 ### Ports for Rancher Server Nodes on K3s
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The K3s server needs port 6443 to be accessible by the nodes.
 
@@ -73,11 +74,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP      | 2376 | Any node IP from a node created using Node driver        | Docker daemon TLS port used by Docker Machine |
 | TCP      | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 Typically Rancher is installed on three RKE nodes that all have the etcd, control plane and worker roles.
 
@@ -118,11 +120,12 @@ The following tables break down the port requirements for inbound and outbound t
 | TCP | 6443 | Hosted/Imported Kubernetes API                           | Kubernetes API server                         |
 | TCP | Provider dependent | Port of the Kubernetes API endpoint in hosted cluster | Kubernetes API |
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Server Nodes on RKE2
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The RKE2 server needs port 6443 and 9345 to be accessible by other nodes in the cluster.
 
@@ -148,11 +151,13 @@ If you wish to utilize the metrics server, you will need to open port 10250 on e
 | HTTPS | 8443 | <ul><li>hosted/registered Kubernetes</li><li>any source that needs to be able to use the Rancher UI or API</li></ul> | Rancher agent, Rancher UI/API, kubectl. Not needed if you have LB doing TLS termination. |
 
 Typically all outbound traffic is allowed.
-{{% /accordion %}}
+
+</details>
 
 ### Ports for Rancher Server in Docker
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following tables break down the port requirements for Rancher nodes, for inbound and outbound traffic:
 
@@ -172,7 +177,7 @@ The following tables break down the port requirements for Rancher nodes, for inb
 | TCP | 2376 | Any node IP from a node created using a node driver | Docker daemon TLS port used by Docker Machine |
 | TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server |
 
-{{% /accordion %}}
+</details>
 
 # Downstream Kubernetes Cluster Nodes
 
@@ -192,7 +197,8 @@ The following diagram depicts the ports that are opened for each [cluster type](
 
 ### Ports for Rancher Launched Kubernetes Clusters using Node Pools
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/).
 
@@ -201,39 +207,42 @@ The following table depicts the port requirements for [Rancher Launched Kubernet
 
 {{< ports-iaas-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Rancher Launched Kubernetes Clusters using Custom Nodes
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with [Custom Nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/).
 
 {{< ports-custom-nodes >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Hosted Kubernetes Clusters
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [hosted clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 ### Ports for Registered Clusters
 
 Note: Registered clusters were called imported clusters before Rancher v2.5.
 
-{{% accordion label="Click to expand" %}}
+<details>
+  <summary>Click to expand</summary>
 
 The following table depicts the port requirements for [registered clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/).
 
 {{< ports-imported-hosted >}}
 
-{{% /accordion %}}
+</details>
 
 
 # Other Port Considerations
@@ -242,7 +251,7 @@ The following table depicts the port requirements for [registered clusters]({{<b
 
 These ports are typically opened on your Kubernetes nodes, regardless of what type of cluster it is.
 
-{{% include file="/rancher/v2.6/en/installation/requirements/ports/common-ports-table" %}}
+{{% include file="/rancher/v2.6/en/installation/requirements/ports/common-ports-table</summary>
 
 ----
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md b/versioned_docs/version-2.6/v2.6/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
index 91972e9aa5f..fc607486482 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/resources/advanced/single-node-install-external-lb/single-node-install-external-lb.md
@@ -40,7 +40,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
 
 Choose from the following options:
 
-{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
+<details id="option-a">
+  <summary>Option A-Bring Your Own Certificate: Self-Signed</summary>
+
 If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
 
 > **Prerequisites:**
@@ -59,8 +61,10 @@ If you elect to use a self-signed certificate to encrypt communication, you must
      rancher/rancher:latest
    ```
 
-{{% /accordion %}}
-{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
+</details>
+<details id="option-b">
+  <summary>Option B-Bring Your Own Certificate: Signed by Recognized CA</summary>
+
 If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
 
 > **Prerequisites:**
@@ -79,7 +83,7 @@ If you use a certificate signed by a recognized CA, installing your certificate
         rancher/rancher:latest --no-cacerts
         ```
 
-    {{% /accordion %}}
+</details>
 
 ## 3. Configure Load Balancer
 
diff --git a/versioned_docs/version-2.6/v2.6/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md b/versioned_docs/version-2.6/v2.6/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
index f3b21f8aed0..393152b315d 100644
--- a/versioned_docs/version-2.6/v2.6/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
+++ b/versioned_docs/version-2.6/v2.6/en/installation/resources/upgrading-cert-manager/upgrading-cert-manager.md
@@ -19,7 +19,7 @@ To address these changes, this guide will do two things:
 
 > 1. Take a one-time snapshot of your Kubernetes cluster running Rancher server
 > 2. Uninstall Rancher, cert-manager, and the CustomResourceDefinition for cert-manager
-> 3. Install the newer version of Rancher and cert-manager 
+> 3. Install the newer version of Rancher and cert-manager
 
 > The reason is that when Helm upgrades Rancher, it will reject the upgrade and show error messages if the running Rancher app does not match the chart template used to install it. Because cert-manager changed its API group and we cannot modify released charts for Rancher, there will always be a mismatch on the cert-manager's API version, therefore the upgrade will be rejected.
 
@@ -31,7 +31,9 @@ In order to upgrade cert-manager, follow these instructions:
 
 ### Option A: Upgrade cert-manager with Internet Access
 
-{{% accordion id="normal" label="Click to expand" %}}
+<details id="normal">
+  <summary>Click to expand</summary>
+
 1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution
 
     ```plain
@@ -87,7 +89,7 @@ In order to upgrade cert-manager, follow these instructions:
     helm install \
       cert-manager jetstack/cert-manager \
       --namespace cert-manager \
-      --version v0.12.0 
+      --version v0.12.0
     ```
 
 1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources)
@@ -96,11 +98,12 @@ In order to upgrade cert-manager, follow these instructions:
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
 ### Option B: Upgrade cert-manager in an Air Gap Environment
 
-{{% accordion id="airgap" label="Click to expand" %}}
+<details id="airgap">
+  <summary>Click to expand</summary>
 
 ### Prerequisites
 
@@ -203,9 +206,9 @@ Before you can perform the upgrade, you must prepare your air gapped environment
     kubectl apply -f cert-manager-backup.yaml
     ```
 
-{{% /accordion %}}
+</details>
 
-### Verify the Deployment 
+### Verify the Deployment
 
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods:
 
diff --git a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
index 5b1141b1f7c..54cb32432b4 100644
--- a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
+++ b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-kubectl/manage-hpa-with-kubectl.md
@@ -64,7 +64,7 @@ spec:
 ```
 
 
-Directive | Description  
+Directive | Description
 ---------|----------|
  `apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
  `name: hello-world` | Indicates that HPA is performing autoscaling for the `hello-word` deployment. |
@@ -76,7 +76,7 @@ Directive | Description
 
 ##### Configuring HPA to Scale Using Resource Metrics (CPU and Memory)
 
-Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler. 
+Clusters created in Rancher v2.0.7 and higher have all the requirements needed (metrics-server and Kubernetes cluster configuration) to use Horizontal Pod Autoscaler.
 
 Run the following commands to check if metrics are available in your installation:
 
@@ -158,7 +158,10 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
     ```
     Then review the log output to confirm the service is running.
-    {{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
+
+    <details id="prometheus-logs">
+      <summary>Prometheus Adaptor Logs</summary>
+
     ...
     I0724 10:18:45.696679       1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
     I0724 10:18:45.696695       1 round_trippers.go:442] Response Headers:
@@ -171,7 +174,8 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     I0724 10:18:45.699939       1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
     I0724 10:18:51.727845       1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
     ...
-    {{% /accordion %}}
+
+    </details>
 
 
 
@@ -182,15 +186,23 @@ For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](
     # kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response" label="API Response" %}}
+
+    <details id="custom-metrics-api-response">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+
+    </details>
 
   - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>`. Add the suffix `/k8s/clusters/<CLUSTER_ID>` to API path.
     ```
     # kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/custom.metrics.k8s.io/v1beta1
     ```
     If the API is accessible, you should receive output that's similar to what follows.
-    {{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
+
+    <details id="custom-metrics-api-response-rancher">
+      <summary>API Response</summary>
+
     {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
-    {{% /accordion %}}
+
+    </details>
diff --git a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
index 93e13be7521..d4990e8516b 100644
--- a/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
+++ b/versioned_docs/version-2.6/v2.6/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md
@@ -9,58 +9,62 @@ For HPA to work correctly, service deployments should have resources request def
 
 1. Configure `kubectl` to connect to your Kubernetes cluster.
 
-2. Copy the `hello-world` deployment manifest below.
-{{% accordion id="hello-world" label="Hello World Manifest" %}}
-```
-apiVersion: apps/v1beta2
-kind: Deployment
-metadata:
-  labels:
-    app: hello-world
-  name: hello-world
-  namespace: default
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: hello-world
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
-    type: RollingUpdate
-  template:
-    metadata:
-      labels:
-        app: hello-world
-    spec:
-      containers:
-      - image: rancher/hello-world
-        imagePullPolicy: Always
-        name: hello-world
-        resources:
-          requests:
-            cpu: 500m
-            memory: 64Mi
-        ports:
-        - containerPort: 80
-          protocol: TCP
-      restartPolicy: Always
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  ports:
-  - port: 80
-    protocol: TCP
-    targetPort: 80
-  selector:
-    app: hello-world
-```
-{{% /accordion %}}
+1. Copy the `hello-world` deployment manifest below.
+
+   <details id="hello-world">
+     <summary>Hello World Manifest</summary>
+
+     ```
+     apiVersion: apps/v1beta2
+     kind: Deployment
+     metadata:
+       labels:
+         app: hello-world
+       name: hello-world
+       namespace: default
+     spec:
+       replicas: 1
+       selector:
+         matchLabels:
+           app: hello-world
+       strategy:
+         rollingUpdate:
+           maxSurge: 1
+           maxUnavailable: 0
+         type: RollingUpdate
+       template:
+         metadata:
+           labels:
+             app: hello-world
+         spec:
+           containers:
+           - image: rancher/hello-world
+             imagePullPolicy: Always
+             name: hello-world
+             resources:
+               requests:
+                 cpu: 500m
+                 memory: 64Mi
+             ports:
+             - containerPort: 80
+               protocol: TCP
+           restartPolicy: Always
+     ---
+     apiVersion: v1
+     kind: Service
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       ports:
+       - port: 80
+         protocol: TCP
+         targetPort: 80
+       selector:
+         app: hello-world
+     ```
+
+   </details>
 
 1. Deploy it to your cluster.
 
@@ -69,423 +73,459 @@ spec:
     ```
 
 1. Copy one of the HPAs below based on the metric type you're using:
-{{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 1000Mi
-```
-{{% /accordion %}}
-{{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
-```
-apiVersion: autoscaling/v2beta1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: hello-world
-  namespace: default
-spec:
-  scaleTargetRef:
-    apiVersion: extensions/v1beta1
-    kind: Deployment
-    name: hello-world
-  minReplicas: 1
-  maxReplicas: 10
-  metrics:
-  - type: Resource
-    resource:
-      name: cpu
-      targetAverageUtilization: 50
-  - type: Resource
-    resource:
-      name: memory
-      targetAverageValue: 100Mi
-  - type: Pods
-    pods:
-      metricName: cpu_system
-      targetAverageValue: 20m
-```
-{{% /accordion %}}
+
+   <details id="service-deployment-resource-metrics">
+     <summary>Hello World HPA: Resource Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 1000Mi
+     ```
+
+   </details>
+   <details id="service-deployment-custom-metrics">
+     <summary>Hello World HPA: Custom Metrics</summary>
+
+     ```
+     apiVersion: autoscaling/v2beta1
+     kind: HorizontalPodAutoscaler
+     metadata:
+       name: hello-world
+       namespace: default
+     spec:
+       scaleTargetRef:
+         apiVersion: extensions/v1beta1
+         kind: Deployment
+         name: hello-world
+       minReplicas: 1
+       maxReplicas: 10
+       metrics:
+       - type: Resource
+         resource:
+           name: cpu
+           targetAverageUtilization: 50
+       - type: Resource
+         resource:
+           name: memory
+           targetAverageValue: 100Mi
+       - type: Pods
+         pods:
+           metricName: cpu_system
+           targetAverageValue: 20m
+     ```
+
+   </details>
 
 1. View the HPA info and description. Confirm that metric data is shown.
-    {{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
-1. Enter the following commands.
-    ```
-    # kubectl get hpa
-    NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
-    hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
-    # kubectl describe hpa
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             1253376 / 100Mi
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
-    {{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive the output that follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             3514368 / 100Mi
-      "cpu_system" on pods:                                0 / 20m
-      resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:           <none>
-    ```
-    {{% /accordion %}}
 
+   <details id="hpa-info-resource-metrics">
+     <summary>Resource Metrics</summary>
+
+     1. Enter the following commands.
+         ```
+         # kubectl get hpa
+         NAME          REFERENCE                TARGETS                     MINPODS   MAXPODS   REPLICAS   AGE
+         hello-world   Deployment/hello-world   1253376 / 100Mi, 0% / 50%   1         10        1          6m
+         # kubectl describe hpa
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 20:21:16 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             1253376 / 100Mi
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
+   <details id="hpa-info-custom-metrics">
+     <summary>Custom Metrics</summary>
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive the output that follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:36:28 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             3514368 / 100Mi
+           "cpu_system" on pods:                                0 / 20m
+           resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:           <none>
+         ```
+
+   </details>
 
 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
 
 1. Test that pod autoscaling works as intended.<br/></br>
   **To Test Autoscaling Using Resource Metrics:**
-  {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. View your HPA.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive output similar to what follows.
-    ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             10928128 / 100Mi
-      resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-      ```
-1. Enter the following command to confirm you've scaled to two pods.
-   ```
-      # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-   ```
-  {{% /accordion %}}
-  {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
+   <details id="observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             9424896 / 100Mi
-        resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-    ```
-2. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-    You should receive output similar to what follows.
-     ```
-      NAME                                                     READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
-      hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
-      hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
-      ```
-  {{% /accordion %}}
-  {{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+     Use your load testing tool to scale up to two pods based on CPU Usage.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             10070016 / 100Mi
-        resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-  ```
-  {{% /accordion %}}
-<br/>
-**To Test Autoscaling Using Custom Metrics:**
-  {{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale two pods based on CPU usage.
+     1. View your HPA.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive output similar to what follows.
+         ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             10928128 / 100Mi
+           resource cpu on pods  (as a percentage of request):  56% (280m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  13s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+           ```
+     1. Enter the following command to confirm you've scaled to two pods.
+        ```
+           # kubectl get pods
+        ```
+        You should receive output similar to what follows:
+        ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          1m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+        ```
 
-1. Enter the following command.
-  ```
-    # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-    Name:                                                  hello-world
-    Namespace:                                             default
-    Labels:                                                <none>
-    Annotations:                                           <none>
-    CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-    Reference:                                             Deployment/hello-world
-    Metrics:                                               ( current / target )
-      resource memory on pods:                             8159232 / 100Mi
-      "cpu_system" on pods:                                7m / 20m
-      resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
-    Min replicas:                                          1
-    Max replicas:                                          10
-    Conditions:
-      Type            Status  Reason              Message
-      ----            ------  ------              -------
-      AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
-      ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-      ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-    Events:
-      Type    Reason             Age   From                       Message
-      ----    ------             ----  ----                       -------
-      Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-  ```
-1. Enter the following command to confirm two pods are running.
-  ```
-    # kubectl get pods
-  ```
-  You should receive output similar to what follows.
-  ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-  ```
-  {{% /accordion %}}
-{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown">
+     <summary>Upscale to 3 pods: CPU Usage Up to Target</summary>
 
-1. Enter the following command.
-   ```
-   # kubectl describe hpa
-   ```
-   You should receive output similar to what follows:
-   ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-    ```
-1. Enter the following command to confirm three pods are running.
-   ```
-   # kubectl get pods
-   ```
-   You should receive output similar to what follows:
-   ```
-      # kubectl get pods
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-   ```
-{{% /accordion %}}
-{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
-Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+     Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes.
 
-1. Enter the following command.
-  ```
-  # kubectl describe hpa
-  ```
-  You should receive output similar to what follows.
-  ```
-      Name:                                                  hello-world
-      Namespace:                                             default
-      Labels:                                                <none>
-      Annotations:                                           <none>
-      CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-      Reference:                                             Deployment/hello-world
-      Metrics:                                               ( current / target )
-        resource memory on pods:                             8374272 / 100Mi
-        "cpu_system" on pods:                                27m / 20m
-        resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
-      Min replicas:                                          1
-      Max replicas:                                          10
-      Conditions:
-        Type            Status  Reason              Message
-        ----            ------  ------              -------
-        AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
-        ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
-        ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-      Events:
-        Type    Reason             Age   From                       Message
-        ----    ------             ----  ----                       -------
-        Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-        Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-        Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-    ```
-1.  Enter the following command to confirm four pods are running.
-    ```
-    # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-      NAME                           READY     STATUS    RESTARTS   AGE
-      hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
-      hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
-      hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
-      hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
-{{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
-Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
-
-1. Enter the following command.
-    ```
-    # kubectl describe hpa
-    ```
-    You should receive similar output to what follows.
-    ```
-        Name:                                                  hello-world
-        Namespace:                                             default
-        Labels:                                                <none>
-        Annotations:                                           <none>
-        CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
-        Reference:                                             Deployment/hello-world
-        Metrics:                                               ( current / target )
-          resource memory on pods:                             8101888 / 100Mi
-          "cpu_system" on pods:                                8m / 20m
-          resource cpu on pods  (as a percentage of request):  0% (0) / 50%
-        Min replicas:                                          1
-        Max replicas:                                          10
-        Conditions:
-          Type            Status  Reason              Message
-          ----            ------  ------              -------
-          AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
-          ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
-          ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
-        Events:
-          Type    Reason             Age   From                       Message
-          ----    ------             ----  ----                       -------
-          Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
-          Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
-          Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
-          Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
-    ```
-1. Enter the following command to confirm a single pods is running.
-    ```
+     1. Enter the following command.
+        ```
+        # kubectl describe hpa
+        ```
+        You should receive output similar to what follows
+        ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             9424896 / 100Mi
+             resource cpu on pods  (as a percentage of request):  66% (333m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  4m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+         ```
+     2. Enter the following command to confirm three pods are running.
+        ```
         # kubectl get pods
-    ```
-    You should receive output similar to what follows.
-    ```
-        NAME                           READY     STATUS    RESTARTS   AGE
-        hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
-    ```
-{{% /accordion %}}
+        ```
+         You should receive output similar to what follows.
+          ```
+           NAME                                                     READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-f46kh                             0/1       Running   0          1m
+           hello-world-54764dfbf8-k8ph2                             1/1       Running   0          5m
+           hello-world-54764dfbf8-q6l4v                             1/1       Running   0          3h
+           ```
+
+   </details>
+   <details id="observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+
+     1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Mon, 23 Jul 2018 22:22:04 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             10070016 / 100Mi
+             resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  10m   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  6m    horizontal-pod-autoscaler  New size: 3; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  1s    horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+       ```
+
+   </details>
+
+   **To Test Autoscaling Using Custom Metrics:**
+
+   <details id="custom-observe-upscale-2-pods-cpu">
+     <summary>Upscale to 2 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale two pods based on CPU usage.
+
+     1. Enter the following command.
+       ```
+         # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+         Name:                                                  hello-world
+         Namespace:                                             default
+         Labels:                                                <none>
+         Annotations:                                           <none>
+         CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+         Reference:                                             Deployment/hello-world
+         Metrics:                                               ( current / target )
+           resource memory on pods:                             8159232 / 100Mi
+           "cpu_system" on pods:                                7m / 20m
+           resource cpu on pods  (as a percentage of request):  64% (321m) / 50%
+         Min replicas:                                          1
+         Max replicas:                                          10
+         Conditions:
+           Type            Status  Reason              Message
+           ----            ------  ------              -------
+           AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 2
+           ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+           ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+         Events:
+           Type    Reason             Age   From                       Message
+           ----    ------             ----  ----                       -------
+           Normal  SuccessfulRescale  16s   horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+       ```
+     1. Enter the following command to confirm two pods are running.
+       ```
+         # kubectl get pods
+       ```
+       You should receive output similar to what follows.
+       ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-5pfdr   1/1       Running   0          3s
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-3-pods-cpu-cooldown-2">
+    <summary>Upscale to 3 Pods: CPU Usage Up to Target</summary>
+
+    Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+
+    1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows:
+       ```
+          Name:                                                  hello-world
+          Namespace:                                             default
+          Labels:                                                <none>
+          Annotations:                                           <none>
+          CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+          Reference:                                             Deployment/hello-world
+          Metrics:                                               ( current / target )
+            resource memory on pods:                             8374272 / 100Mi
+            "cpu_system" on pods:                                27m / 20m
+            resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+          Min replicas:                                          1
+          Max replicas:                                          10
+          Conditions:
+            Type            Status  Reason              Message
+            ----            ------  ------              -------
+            AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+            ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+            ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+          Events:
+            Type    Reason             Age   From                       Message
+            ----    ------             ----  ----                       -------
+            Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+            Normal  SuccessfulRescale  3s    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+        ```
+    1. Enter the following command to confirm three pods are running.
+       ```
+       # kubectl get pods
+       ```
+       You should receive output similar to what follows:
+       ```
+          # kubectl get pods
+          NAME                           READY     STATUS    RESTARTS   AGE
+          hello-world-54764dfbf8-5pfdr   1/1       Running   0          3m
+          hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+          hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+       ```
+
+   </details>
+   <details id="observe-upscale-4-pods">
+     <summary>Upscale to 4 Pods: CPU Usage Up to Target</summary>
+
+     Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+
+     1. Enter the following command.
+       ```
+       # kubectl describe hpa
+       ```
+       You should receive output similar to what follows.
+       ```
+           Name:                                                  hello-world
+           Namespace:                                             default
+           Labels:                                                <none>
+           Annotations:                                           <none>
+           CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+           Reference:                                             Deployment/hello-world
+           Metrics:                                               ( current / target )
+             resource memory on pods:                             8374272 / 100Mi
+             "cpu_system" on pods:                                27m / 20m
+             resource cpu on pods  (as a percentage of request):  71% (357m) / 50%
+           Min replicas:                                          1
+           Max replicas:                                          10
+           Conditions:
+             Type            Status  Reason              Message
+             ----            ------  ------              -------
+             AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 3
+             ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+             ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+           Events:
+             Type    Reason             Age   From                       Message
+             ----    ------             ----  ----                       -------
+             Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+             Normal  SuccessfulRescale  3m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+             Normal  SuccessfulRescale  4s    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+         ```
+     1.  Enter the following command to confirm four pods are running.
+         ```
+         # kubectl get pods
+         ```
+         You should receive output similar to what follows.
+         ```
+           NAME                           READY     STATUS    RESTARTS   AGE
+           hello-world-54764dfbf8-2p9xb   1/1       Running   0          5m
+           hello-world-54764dfbf8-5pfdr   1/1       Running   0          2m
+           hello-world-54764dfbf8-m2hrl   1/1       Running   0          1s
+           hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+         ```
+
+   </details>
+   <details id="custom-metrics-observe-downscale-1-pod">
+     <summary>Downscale to 1 Pod: All Metrics Below Target</summary>
+
+     Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`.
+
+     1. Enter the following command.
+         ```
+         # kubectl describe hpa
+         ```
+         You should receive similar output to what follows.
+         ```
+             Name:                                                  hello-world
+             Namespace:                                             default
+             Labels:                                                <none>
+             Annotations:                                           <none>
+             CreationTimestamp:                                     Tue, 24 Jul 2018 18:01:11 +0200
+             Reference:                                             Deployment/hello-world
+             Metrics:                                               ( current / target )
+               resource memory on pods:                             8101888 / 100Mi
+               "cpu_system" on pods:                                8m / 20m
+               resource cpu on pods  (as a percentage of request):  0% (0) / 50%
+             Min replicas:                                          1
+             Max replicas:                                          10
+             Conditions:
+               Type            Status  Reason              Message
+               ----            ------  ------              -------
+               AbleToScale     True    SucceededRescale    the HPA controller was able to update the target scale to 1
+               ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
+               ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
+             Events:
+               Type    Reason             Age   From                       Message
+               ----    ------             ----  ----                       -------
+               Normal  SuccessfulRescale  10m    horizontal-pod-autoscaler  New size: 2; reason: cpu resource utilization (percentage of request) above target
+               Normal  SuccessfulRescale  8m    horizontal-pod-autoscaler  New size: 3; reason: pods metric cpu_system above target
+               Normal  SuccessfulRescale  5m    horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization (percentage of request) above target
+               Normal   SuccessfulRescale             13s               horizontal-pod-autoscaler  New size: 1; reason: All metrics below target
+         ```
+     1. Enter the following command to confirm a single pods is running.
+         ```
+             # kubectl get pods
+         ```
+         You should receive output similar to what follows.
+         ```
+             NAME                           READY     STATUS    RESTARTS   AGE
+             hello-world-54764dfbf8-q6l82   1/1       Running   0          6h
+         ```
+
+   </details>
diff --git a/versioned_docs/version-2.6/v2.6/en/overview/overview.md b/versioned_docs/version-2.6/v2.6/en/overview/overview.md
index 22d719374d7..c37ce96c536 100644
--- a/versioned_docs/version-2.6/v2.6/en/overview/overview.md
+++ b/versioned_docs/version-2.6/v2.6/en/overview/overview.md
@@ -50,7 +50,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
 ### Cluster Visibility
 
 - **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
-- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution. 
+- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
 - **Alerting:** To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned.
 
 # Editing Downstream Clusters with Rancher
@@ -61,4 +61,4 @@ After a cluster is created with Rancher, a cluster administrator can manage clus
 
 The following table summarizes the options and settings available for each cluster type:
 
-{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table" %}}
+{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>