Skip to content

Commit

Permalink
k8s/controlplane: apply review suggestions and clarifications
Browse files Browse the repository at this point in the history
Co-authored-by: Paolo Gallina <paologallina1992@gmail.com>
  • Loading branch information
roobre and paologallinaharbur committed Jan 31, 2022
1 parent 38aa76f commit f0680dd
Showing 1 changed file with 6 additions and 7 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ redirects:
- /docs/integrations/kubernetes-integration/installation/configure-control-plane-monitoring
---

[New Relic](/docs/infrastructure/new-relic-infrastructure/getting-started/introduction-new-relic-infrastructure) provides [control plane](http://kubernetes.io/docs/concepts/#kubernetes-control-plane) support for your Kubernetes integration, allowing you to monitor and collect metrics from your cluster's control plane components. That data can then be found in New Relic and used to [create queries and charts](/docs/using-new-relic/data/understand-data/query-new-relic-data).
[New Relic](/docs/infrastructure/new-relic-infrastructure/getting-started/introduction-new-relic-infrastructure) provides [control plane](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) support for your Kubernetes integration, allowing you to monitor and collect metrics from your cluster's control plane components. That data can then be found in New Relic and used to [create queries and charts](/docs/using-new-relic/data/understand-data/query-new-relic-data).

<Callout variant="tip">
Unless otherwise specified, this page refers to the [Kubernetes integration v3](/docs/kubernetes-pixie/kubernetes-integration/get-started/changes-since-v3). Details on how to configure control plane monitoring for v2 can be found in a specific section below.
Expand All @@ -26,9 +26,8 @@ We monitor and collect [metrics](http://docs.newrelic.com/docs/integrations/kube

## Compatibility and requirements [#compatibility]

* Control plane monitoring requires [Kubernetes integration version 1.16.0 or higher](/docs/release-notes/infrastructure-release-notes/kubernetes-integration-release-notes/).
* Control plane monitoring support is limited for managed clusters. This is because most cloud providers do not expose the metrics endpoints for the control plane components, so New Relic cannot access them.
* When deploying the solution in [unprivileged mode](/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration#unprivileged), control plane setup will require extra steps and some caveats might apply.
* When deploying the solution in [unprivileged mode](/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration#unprivileged), control plane setup will require [extra steps](#hostnetwork-privileged) and some caveats might apply.
* [OpenShift](http://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001OH7iAAG) 4.x uses control plane component metric endpoints that are different than the default.

## Control plane component [#component]
Expand All @@ -55,9 +54,9 @@ By default, our [Helm Chart](/docs/kubernetes-pixie/kubernetes-integration/insta

Most users and Kubernetes distributions configure the control plane metrics endpoints to listen only in the loopback interface, i.e. `localhost`. For this reason, the control plane component is deployed with `hostNetwork: true` by default when `privileged` is set to `true` (the default).

To honor the master `privileged` setting, `hostNetwork` will be set to `false` if `privileged` is set to `false`. This will cause control plane scraping to fail in most environments, which will result in missing metrics or the `nrk8s-controlplane` pods getting stuck into a `CrashLoopBackoff` state. This is a limitation of Kubernetes itself, as control plane cannot be monitored without `hostNetwork` unless components are manually configured to do so.
When the integration is deployed using `privileged: false`, the `hostNetwork` setting for the control plane component will be also be set to `false`. We chose to do it this way because otherwise, we would not be honoring the intent users have when they set `privileged: false`. Unfortunately, deploying without `hostNetwork` will cause control plane scraping to fail in most environments, which will result in missing metrics or the `nrk8s-controlplane` pods getting stuck into a `CrashLoopBackoff` state. This is a limitation of Kubernetes itself, as control plane cannot be monitored without `hostNetwork` unless components are manually configured to do so.

However, it is a common setting to deploy the integration in unprivileged mode (`privileged: false`), but still consider acceptable running the control plane pods with `hostNetwork`. This can be achieving by setting `controlPlane.unprivilegedHostNetwork` to `true`: This will tell the chart to deploy the control plane component with `hostNetwork: true`, despite the value of the higher-level `privileged` flag.
As it is a common setting to deploy the integration in unprivileged mode (`privileged: false`), but still consider acceptable running the control plane pods with `hostNetwork`. This can be achieving by setting `controlPlane.unprivilegedHostNetwork` to `true`: This will tell the chart to deploy the control plane component with `hostNetwork: true`, despite the value of the higher-level `privileged` flag.

If running pods with `hostNetwork` is not acceptable whatsoever, due to cluster or other policies, control plane monitoring is not possible and should be disabled by setting `controlPlane.enabled` to `false`.

Expand Down Expand Up @@ -166,10 +165,10 @@ Please keep in mind that if `staticEndpoint` is set, the `autodiscover` section
#### Limitations [#static-endpoints-limitations]

<Callout variant="important">
If you are using `staticEndpoint`, you must change `controlPlane.kind` from `DaemonSet` to `Deployment`.
If you are using `staticEndpoint` pointing to an out-of-node (i.e. not `localhost`) endpoint, you must change `controlPlane.kind` from `DaemonSet` to `Deployment`.
</Callout>

When using `staticEndpoint`, all `nrk8s-controlplane` pods will attempt to reach and scrape said endpoint. This means that, if `nrk8s-controlplane` is a DaemonSet (the default), your components will get scraped multiple times, potentially leading to duplicate metrics and increased billable usage. If you are using `staticEndpoint`, make sure to change `controlPlane.kind` to Deployment.
When using `staticEndpoint`, all `nrk8s-controlplane` pods will attempt to reach and scrape said endpoint. This means that, if `nrk8s-controlplane` is a DaemonSet (the default), all instances of the DaemonSet will scrape this endpoint. While this is fine if you are pointing them to `localhost`, if the endpoint is not local to the node you could potentially produce to duplicate metrics and increased billable usage. If you are using `staticEndpoint` and pointing it to a non-local URL, make sure to change `controlPlane.kind` to Deployment.

For the same reason above, it is currently not possible to use autodiscovery for some control plane components, and a static endpoint for others. This is a know limitation we are working to address in future versions of the integration.

Expand Down

0 comments on commit f0680dd

Please sign in to comment.