Add documentation for claiming k8s parent pods and Prometheus service discovery

claim/README.md

@@ -135,6 +135,11 @@ with the name of your container if different.
 docker logs netdata 2>&1 | grep -E --line-buffered 'ACLK|claim|cloud'
 ```
 
+### Claim a Kubernetes cluster's parent Netdata pod
+
+Read our [Kubernetes installation](/packaging/installer/methods/kubernetes.md#claim-a-kubernetes-clusters-parent-pod)
+for details on claiming a parent Netdata pod.
+
 ### Claim through a proxy
 
 A Space's administrator can claim a node through a SOCKS5 or HTTP(S) proxy.

docs/guides/monitor/kubernetes-k8s-netdata.md

@@ -29,8 +29,10 @@ your k8s infrastructure.
 -   A [Helm chart](https://github.com/netdata/helmchart), which bootstraps a Netdata Agent pod on every node in your
     cluster, plus an additional parent pod for storing metrics and managing alarm notifications.
 -   A [service discovery plugin](https://github.com/netdata/agent-service-discovery), which discovers and immediately
-    monitors 22 different services that might be running inside of your cluster's pods. Service discovery happens
-    without manual intervention as pods are created, destroyed, or moved between nodes. [Compatible
+    monitors 23 specific services, plus any endpoints covered by our [generic Prometheus
+    collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus), that might be running
+    inside of your cluster's pods. Service discovery happens without manual intervention as pods are created, destroyed,
+    or moved between nodes. [Compatible
     services](https://github.com/netdata/helmchart#service-discovery-and-supported-services) include Nginx, Apache,
     MySQL, CoreDNS, and much more.
 -   A [Kubelet collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/k8s_kubelet), which runs
@@ -143,9 +145,10 @@ Thanks to Netdata's service discovery feature, you monitor containerized applica
 configuration or manual intervention. Service discovery is like a watchdog for created or deleted pods, recognizing the
 service they run based on the image name and port and immediately attempting to apply a logical default configuration.
 
-Service configuration supports [22
-services](https://github.com/netdata/helmchart#service-discovery-and-supported-services), which are automatically added
-or removed from Netdata as soon as the pods are created or destroyed.
+Service configuration supports [23
+services](https://github.com/netdata/helmchart#service-discovery-and-supported-services), plus any endpoints covered by
+our [generic Prometheus collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus),
+which are automatically added or removed from Netdata as soon as the pods are created or destroyed.
 
 You can find these service discovery sections near the bottom of the menu. The names for these sections follow a
 pattern: the name of the detected service, followed by a string of the module name, pod TUID, service type, port

docs/guides/monitor/pi-hole-raspberry-pi.md

@@ -31,8 +31,8 @@ directly using a keyboard, mouse, and monitor.
 Netdata helps you monitor and troubleshoot all kinds of devices and the applications they run, including IoT devices
 like the Raspberry Pi and applications like Pi-hole.
 
-After a two-minute installation and with zero configuration, you'll be able all of Pi-hole's metrics, including the
-volume of queries, connected clients, DNS queries per type, top clients, top blocked domains, and more.
+After a two-minute installation and with zero configuration, you'll be able to seeall of Pi-hole's metrics, including
+the volume of queries, connected clients, DNS queries per type, top clients, top blocked domains, and more.
 
 With Netdata installed, you can also monitor system metrics and any other applications you might be running. By default,
 Netdata collects metrics on CPU usage, disk IO, bandwidth, per-application resource usage, and a ton more. With the

packaging/installer/methods/kubernetes.md

@@ -11,9 +11,10 @@ will use Netdata's [Helm chart](https://github.com/netdata/helmchart) to bootstr
 The Helm chart installs one parent pod for storing metrics and managing alarm notifications plus an additional child pod
 for every node in the cluster.
 
-Each child pod will collect metrics from the node it runs on in addition to [22 supported
-services](https://github.com/netdata/helmchart#service-discovery-and-supported-services) via [service
-discovery](https://github.com/netdata/agent-service-discovery/). Each child pod will also collect
+Each child pod will collect metrics from the node it runs on, in addition to [23 specific
+services](https://github.com/netdata/helmchart#service-discovery-and-supported-services), plus any endpoints covered by
+our [generic Prometheus collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus),
+via [service discovery](https://github.com/netdata/agent-service-discovery/). Each child pod will also collect
 [cgroups](/collectors/cgroups.plugin/README.md),
 [Kubelet](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/k8s_kubelet), and
 [kube-proxy](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/k8s_kubeproxy) metrics from its node.
@@ -84,8 +85,9 @@ metrics from the service they run. The Netdata Helm chart installs this service
 
 Service discovery scans your cluster for pods exposed on certain ports and with certain image names. By default, it
 looks for its supported services on the ports they most commonly listen on, and using default image names. Service
-discovery currently supports [22 popular
-services](https://github.com/netdata/helmchart#service-discovery-and-supported-services).
+discovery currently supports [23 popular
+services](https://github.com/netdata/helmchart#service-discovery-and-supported-services), plus any endpoints covered by
+our [generic Prometheus collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus).
 
 If you haven't changed listening ports or other defaults, service discovery should find your pods, create the proper
 configurations based on the service that pod runs, and begin monitoring them immediately after depolyment.
@@ -138,6 +140,52 @@ netdata              LoadBalancer   10.245.160.131   203.0.113.0    19999:32231/
 
 In the above example, access the dashboard by navigating to `http://203.0.113.0:19999`.
 
+## Claim a Kubernetes cluster's parent pod
+
+You can [claim](/claim/README.md) a cluster's parent Netdata pod to see its real-time metrics alongside any other nodes
+you monitor using [Netdata Cloud](https://app.netdata.cloud).
+
+> Netdata Cloud does not currently support claiming child nodes because the Helm chart does not allocate a persistent
+> volume for them.
+
+Ensure persistence is enabled on the parent pod by running the following `helm upgrade` command.
+
+```bash
+helm upgrade \
+  --set parent.database.persistence=true \
+  --set parent.alarms.persistence=true \
+  netdata ./netdata-helmchart
+```
+
+Next, find your claiming script in Netdata Cloud by clicking on your Space's dropdown, then **Manage your Space**. Click
+the **Nodes** tab. Netdata Cloud shows a script similar to the following:
+
+```bash
+sudo netdata-claim.sh -token=TOKEN -rooms=ROOM1,ROOM2 -url=https://app.netdata.cloud
+```
+
+You will need the values of `TOKEN` and `ROOM1,ROOM2` for the command, which sets `parent.claiming.enabled`,
+`parent.claiming.token`, and `parent.claiming.rooms` to complete the parent pod claiming process.
+
+Run the following `helm upgrade` command after replacing `TOKEN` and `ROOM1,ROOM2` with the values found in the claiming
+script from Netdata Cloud. The quotations are required.
+
+```bash
+helm upgrade \
+  --set parent.claiming.enabled=true \
+  --set parent.claiming.token="TOKEN" \
+  --set parent.claiming.rooms="ROOM1,ROOM2" \
+  netdata ./netdata-helmchart
+```
+
+The cluster terminates the old parent pod and creates a new one with the proper claiming configuration. You can see your
+parent pod in Netdata Cloud after a few moments. You can now [build new
+dashboards](https://learn.netdata.cloud/docs/cloud/visualize/dashboards) using the parent pod's metrics or run [Metric
+Correlations](https://learn.netdata.cloud/docs/cloud/insights/metric-correlations) to troubleshoot anomalies.
+
+![A parent Netdata pod in Netdata
+Cloud](https://user-images.githubusercontent.com/1153921/94497340-c1f49880-01ab-11eb-97b2-6044537565af.png)
+
 ## Update/reinstall the Netdata Helm chart
 
 If you update the Helm chart's configuration, run `helm upgrade` to redeploy your Netdata service, replacing `netdata`