Resources

Installing Kubelet Stats Receiver with OpenTelemetry

October 1, 2024 by OpenObserve Team
Kubelet Stats Receiver

Your Kubernetes cluster is a complex ecosystem teeming with data. To harness its full potential, you need powerful tools. The Kubelet Stats Receiver is a cornerstone of effective Kubernetes cluster monitoring. 

The Kubelet Stats Receiver is a critical component within the OpenTelemetry Collector architecture for gathering metrics from Kubernetes nodes. It interacts directly with the Kubelet, a control plane agent that runs on each node.

Key Functions:

  • Metric Collection: Periodically fetches metrics such as CPU, memory, network, and disk utilization from the Kubelet.
  • Data Enrichment: Adds context to collected metrics, including pod and container information.
  • Data Export: Sends enriched metrics to the OpenTelemetry Collector for further processing and analysis.

Integration with OpenTelemetry:

The Kubelet Stats Receiver is integrated with the OpenTelemetry Collector, which is responsible for receiving, processing, and exporting telemetry data. The collector can then forward the metrics to various backend systems for storage and visualization.

Importance of Kubelet Stats Receiver:

  • Real-time monitoring: Provides up-to-date insights into cluster health and resource utilization.
  • Capacity planning: Helps in predicting future resource needs.
  • Performance optimization: Identifies bottlenecks and optimization opportunities.
  • Anomaly detection: Detects abnormal resource usage patterns.

By effectively utilizing the Kubelet Stats Receiver, organizations can gain valuable insights into their Kubernetes clusters and make data-driven decisions. Let’s get started by understanding the deployment and configuration of OpenTelemetry collector.

Deployment and Configuration

To install the Kubelet Stats Receiver with OpenTelemetry in OpenObserve, follow these steps:

Deploying the OpenTelemetry Collector

The OpenTelemetry Collector can be deployed in various ways, including as a Docker container, using Docker Compose, or on Kubernetes. The key steps are:

  1. Pull the OpenTelemetry Collector Docker image:

Bash
docker pull otel/opentelemetry-collector-contrib:0.103.1

  1. Run the Collector container, mounting a custom configuration file:

Bash
docker run -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml otel/opentelemetry-collector-contrib:0.103.1

Configuring the OpenTelemetry Collector

In the OpenTelemetry Collector configuration, add the following receiver and exporter to collect Kubelet metrics:

Bash
receivers:
  kubeletstats:
    collection_interval: 10s
    endpoint: 0.0.0.0:10250
    metric_groups:
      - container
      - node
      - pod
      - volume

exporters:
  openobserve:
    endpoint: https://openobserve.example.com
    api_key: your_api_key

Replace https://openobserve.example.com with your OpenObserve cluster URL and your_api_key with a valid API key.

Verifying the Installation

After restarting the OpenTelemetry Collector, you should see Kubelet metrics in OpenObserve within a few minutes. You can verify this by running a query in the OpenObserve UI or using the API:

sql
SELECT * FROM metrics WHERE metric_name LIKE 'kube%'

This query will return all Kubelet-related metrics being collected by OpenTelemetry and sent to OpenObserve.

By following these steps, you can successfully install the Kubelet Stats Receiver with OpenTelemetry and start collecting Kubelet metrics in your OpenObserve observability platform. To know more about how to use OpenObserve, check out the detailed documentation here.

Now, let’s understand the authentication and permissions required. 

Authentication and Permissions

Here are the key points about authentication and permissions for the Kubelet Stats Receiver with OpenTelemetry in OpenObserve:

Service Account Authentication

  • Use auth_type: "serviceAccount" in the receiver configuration
  • Requires the default service account token to authenticate to the kubelet API
  • The pod spec should set the node name using the downward API:

Bash
env:
- name: K8S_NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

  • Then reference the K8S_NODE_NAME environment variable in the endpoint field:

Bash
receivers:
  kubeletstats:
    auth_type: "serviceAccount"
    endpoint: "${K8S_NODE_NAME}:10250"

TLS Authentication

  • Use auth_type: "tls" in the receiver configuration
  • Requires setting ca_file, key_file, and cert_file fields
  • Example configuration:

Bash
receivers:
  kubeletstats:
    auth_type: "tls"
    ca_file: "/path/to/ca.crt"
    key_file: "/path/to/apiserver.key"
    cert_file: "/path/to/apiserver.crt"
    endpoint: "192.168.64.1:10250"

Required Permissions

  • The Kubelet Stats Receiver needs get permissions on the nodes/stats resources
  • If using extra_metadata_labels or request/limit_utilization metrics, it also needs get permissions on nodes/proxy resources
  • Example RBAC configuration:

Bash
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector
rules:
- apiGroups: [""]
  resources: ["nodes/stats"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

By following these authentication and permission guidelines, you can successfully configure the Kubelet Stats Receiver to collect metrics from the kubelet API in your OpenObserve setup. Let’s see a sample configuration file and parameters to go with it.

Sample Configuration

Here's a sample configuration for the Kubelet Stats Receiver with OpenTelemetry in OpenObserve:

Example Configuration File

Bash
receivers:
  kubeletstats:
    collection_interval: 10s
    endpoint: "${K8S_NODE_NAME}:10250"
    auth_type: "serviceAccount"
    metric_groups:
      - container
      - node
      - pod
      - volume
    extra_metadata_labels:
      - "kubernetes.io/hostname"
      - "beta.kubernetes.io/instance-type"
    request_limit_utilization:
      enabled: true
      threshold: 80

exporters:
  openobserve:
    endpoint: https://openobserve.example.com
    api_key: your_api_key

Configuration Parameters

Mandatory Parameters

  • collection_interval: Interval at which to collect metrics (e.g., "10s")
  • endpoint: Kubelet API endpoint (e.g., "${K8S_NODE_NAME}:10250")
  • auth_type: Authentication type, either "serviceAccount" or "tls"

Optional Parameters

  • metric_groups: Specify which metric groups to collect (container, node, pod, volume)
  • extra_metadata_labels: Additional labels to include in the metrics (e.g., "kubernetes.io/hostname")
  • request_limit_utilization:
  • enabled: Enable request/limit utilization metrics
  • threshold: Threshold percentage for request/limit utilization (e.g., 80)
  • ca_file, key_file, cert_file: Required for "tls" auth_type

In the OpenObserve exporter configuration:

  • endpoint: OpenObserve cluster URL (e.g., https://openobserve.example.com)
  • api_key: Valid API key for authentication

This sample configuration demonstrates the key parameters for the Kubelet Stats Receiver and OpenObserve exporter. Adjust the values based on your specific requirements and environment. In the next section, we will discuss a few advanced configuration options.

Advanced Configuration Options

Here are the key advanced configuration options for installing the Kubelet Stats Receiver with OpenTelemetry:

Including/excluding specific metrics

You can configure which metric groups to collect by setting the metric_groups option in the receiver configuration. The available groups are:

  • node: Node-level metrics
  • pod: Pod metrics
  • container: Container metrics
  • volume: Volume metrics

For example, to collect only node and pod metrics:

Bash
receivers:
  kubeletstats:
    metric_groups:
      - node
      - pod

Adding additional metadata attributes

You can add extra metadata labels to the collected metrics by setting the extra_metadata_labels option. This requires get permissions on the nodes/proxy resource in addition to nodes/stats.

Bash
receivers:
  kubeletstats:
    extra_metadata_labels:
      - node_name
      - pod_name
      - container_name

Configuring collection intervals and security settings

The collection_interval option sets how often metrics are collected, defaulting to 10 seconds.

The auth_type option configures how the receiver authenticates to the kubelet API. The available options are:

  • none: Use the read-only kubelet endpoint on port 10255 (no auth required)
  • tls: Use TLS auth with the specified ca_file, cert_file, and key_file
  • serviceAccount: Use the pod's service account token and CA cert
  • kubeConfig: Use the specified kubeConfig file to authenticate and proxy through the API server

Bash
receivers:
  kubeletstats:
    collection_interval: 10s
    auth_type: serviceAccount
    endpoint: "${env:K8S_NODE_NAME}:10250"
    insecure_skip_verify: true

The insecure_skip_verify option disables TLS cert verification when set to true.

Role-based access control

The Kubelet Stats Receiver requires get permissions on the nodes/stats resource. If using extra_metadata_labels or request/limit utilization metrics, it also needs access to nodes/proxy.

Bash
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: otel-collector
rules:
- apiGroups: [""]
  resources: ["nodes/stats"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

By leveraging these advanced configuration options, you can fine-tune the Kubelet Stats Receiver to collect the exact metrics you need, add relevant metadata, and optimize collection intervals and security settings to best fit your observability requirements when using OpenTelemetry.

Monitoring and Metrics

Here are the key points about the available metrics and resource attributes for the Kubelet Stats Receiver:

Available metrics

The Kubelet Stats Receiver collects the following metric groups from the kubelet API:

  • Node metrics: CPU, memory, filesystem, network, and volume metrics at the node level
  • Pod metrics: CPU, memory, network, and volume metrics at the pod level
  • Container metrics: CPU, memory, and filesystem metrics at the container level
  • Volume metrics: Capacity, available, used, and inodes metrics for volumes

Resource attributes

The receiver automatically adds the following resource attributes to the collected metrics:

  • k8s.cluster.name: Name of the Kubernetes cluster
  • k8s.node.name: Name of the node
  • k8s.pod.name: Name of the pod
  • k8s.container.name: Name of the container
  • k8s.volume.name: Name of the volume

You can also configure additional metadata labels to be added using the extra_metadata_labels option, such as:

  • node_name
  • pod_name
  • container_name

This allows enriching the metrics with more context about the origin of the data.

Metric types

The metrics collected are of the following types:

  • Counters: Monotonically increasing values, like CPU time
  • Gauges: Values that can go up or down, like memory usage
  • Histograms: Distributions of values, like latency

This rich set of node, pod, container and volume metrics along with the associated resource attributes can help you gain deep visibility into the performance and health of your Kubernetes cluster using the Kubelet Stats Receiver.

Troubleshooting and Support

Unable to get network stats in OpenShift 4

  • If you are running the OpenObserve Collector in OpenShift 4 and unable to get network stats, ensure you have the correct RBAC permissions set up. 
  • The Kubelet Stats Receiver needs ‘get’ permissions on the nodes/stats resource. If using extra_metadata_labels or request/limit utilization metrics, it also needs access to nodes/proxy.

Metrics not showing up

  • Check that the Kubelet Stats Receiver is properly configured in your OpenObserve Collector config. 
  • Ensure the kubeletstats receiver is included in the receivers section and the metrics pipeline.
  • Verify the auth_type is set correctly. If using tls, make sure the ca_file, cert_file, and key_file are specified. For serviceAccount, ensure the pod has the necessary permissions.

Incomplete metrics

  • By default, the Kubelet Stats Receiver collects node, pod and container metrics. 
  • To collect volume metrics as well, set metric_groups to include volume.

Getting support

For general questions and troubleshooting, you can reach out to the OpenObserve community on Github.

By following these troubleshooting steps and leveraging the OpenObserve community support, you should be able to resolve most issues encountered when using the Kubelet Stats Receiver. 

Why OpenObserve is the Right Choice

OpenObserve is the ideal choice for analyzing and visualizing the metrics collected by the Kubelet Stats Receiver. With its powerful querying capabilities, customizable dashboards, and alerting features, OpenObserve enables you to:

  • Quickly identify performance bottlenecks and anomalies
  • Optimize resource utilization and plan for future capacity needs
  • Correlate metrics across different layers of your stack
  • Collaborate with your team and share insights

Sign up for OpenObserve Today

To get started with OpenObserve, sign up for a free trial. Our team is dedicated to helping you achieve observability and gain actionable insights from your Kubernetes metrics.

Don't miss out on the benefits of comprehensive Kubernetes monitoring with OpenObserve. Sign up today and take your observability to the next level!

Author:

authorImage

The OpenObserve Team comprises dedicated professionals committed to revolutionizing system observability through their innovative platform, OpenObserve. Dedicated to streamlining data observation and system monitoring, offering high performance and cost-effective solutions for diverse use cases.

OpenObserve Inc. © 2024