diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
index 2a86ca345b5..0286f4c55df 100644
--- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/_index.md
@@ -254,6 +254,8 @@ bdf3898b8063        rancher/hyperkube:v1.11.5-rancher1   "/opt/rke-tools/en..."
 
 ### controlplane container logging
 
+> **Note:** If you added multiple nodes with the `controlplane` role, both `kube-controller-manager` and `kube-scheduler` use a leader election process to determine the leader. Only the current leader will log the performed actions. See [Kubernetes leader election]({{< baseurl >}}/rancher/v2.x/en/troubleshooting/kubernetes-resources/#kubernetes-leader-election) how to retrieve the current leader.
+
 The logging of the containers can contain information on what the problem could be.
 
 ```
diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
index 27edf463013..f86e0aa63cc 100644
--- a/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-resources/_index.md
@@ -50,6 +50,26 @@ Example output:
 worker-0: DiskPressure:True
 ```
 
+### Kubernetes leader election
+
+#### Kubernetes Controller Manager leader
+
+The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `kube-controller-manager` endpoint (in this example, `controlplane-0`).
+
+```
+kubectl -n kube-system get endpoints kube-controller-manager -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
+{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
+```
+
+#### Kubernetes Scheduler leader
+
+The leader is determined by a leader election process. After the leader has been determined, the leader (`holderIdentity`) is saved in the `kube-scheduler` endpoint (in this example, `controlplane-0`).
+
+```
+kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
+{"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>
+```
+
 ### Ingress Controller
 
 The default Ingress Controller is NGINX and is deployed as a DaemonSet in the `ingress-nginx` namespace. The pods are only scheduled to nodes with the `worker` role.
diff --git a/content/rancher/v2.x/en/troubleshooting/networking/_index.md b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
index 689629c2b16..9d107228d90 100644
--- a/content/rancher/v2.x/en/troubleshooting/networking/_index.md
+++ b/content/rancher/v2.x/en/troubleshooting/networking/_index.md
@@ -99,7 +99,7 @@ If there is no output, the cluster is not affected.
 
 #### System namespace pods network connectivity broken
 
-> Note: This applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
+> **Note:** This applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
 
 | | |
 |------------|------------|