This document discusses using InfluxDB and Kubernetes for monitoring. It provides an overview of deploying InfluxDB and Chronograf using Helm charts. It also describes monitoring Kubernetes infrastructure by deploying Telegraf as a DaemonSet to collect metrics from nodes. Additionally, it covers monitoring applications by deploying Telegraf as a single pod to scrape metrics or as a sidecar. Lastly, it discusses future plans for an InfluxData operator and running InfluxEnterprise outside Kubernetes clusters.
5. Monitoring Kubernetes Infrastructure
• Gathering CPU, Memory, Disk, Network, etc.
– Any infrastructure metric interesting per node
• Deploy Telegraf Agent as DaemonSet
• Store common ConfigMap for all Nodes
• Store sensitive values as a Secret
• Helm chart: telegraf-ds
7. Useful Telegraf Plugins per Node
• cpu
– Collects standard CPU metrics as
defined in `man proc`
• disk
– Gathers metrics about disk usage
• docker
– Uses the Official Docker Client to
gather stats from the Engine API
• diskio
– Gathers metrics about disk traffic
and timing
• kernel
– Gathers info about the kernel that
doesn't fit into other plugins
• kubernetes
– Talks to the kubelet api using the
/stats/summary endpoint
• mem
– Collects system memory metrics
• processes
– Gathers info about the total number
of processes and groups them by
status
• swap
– Collects system swap metrics
• system
– Gathers general stats on system
load, uptime
8. Monitoring Kubernetes Applications (Single Instance)
• Deploy Telegraf as a single pod and configure it to listen for or
scrape metrics from other pods in the cluster
• Great for scraping Prometheus /metrics endpoints
– Leverages Kube DNS to discover pods
• http://<service-name>.<namespace>:<port>/metrics
• Great for forwarding metrics and logs to InfluxDB
• Helm chart: telegraf-s
10. Monitoring Kubernetes Applications (Sidecar Pattern)
• Deploy Telegraf as a sidecar container inside your Pods
• Allows you to be explicit in all your monitoring
• Configuration is as simple as using localhost
• Most apps don’t have a /metrics endpoint
• No Helm chart, but check out
– https://www.influxdata.com/blog/monitoring-kubernetes-architecture/
12. InfluxOSS 1.x and Kubernetes
• Continue to enhance the existing Helm charts
• Develop native Kubernetes Operator for InfluxData
– This will be the easiest way to deploy and manage Influx Products in
Kubernetes
– Starting with InfluxDB, but will eventually expand to all products
• Bring deployment documentation and recommendations to one
place
14. InfluxEnterprise and Kubernetes
• We recommend you continue to run production InfluxEnterprise
outside your Kubernetes clusters
• Leverage Terraform modules for quickly deploying in cloud env
• Entire InfluxData 2.x Platform will be built on Kubernetes
17. Example ConfigMap
Use a separate
namespace for your
monitoring components
These values can be
pulled from a secret
Pulls stats from local
kubelet /stats/summary