Checkmk brings infrastructure health into a monitoring system where teams can inspect status and respond to alerts. For Kubernetes, its collectors gather information about the cluster, its machines and the workloads running on them. It is useful when Kubernetes needs to be monitored alongside the rest of your infrastructure. Installing those collectors connects cluster information to Checkmk; it does not, by itself, create and operate the complete monitoring service.
Deployment and operating notes
The recovered description reflects an older Check_MK monitoring stack. Current Checkmk documentation describes Kubernetes API collection plus Node Collector and Cluster Collector components, installed using the project’s Helm chart. Installing those collectors monitors Kubernetes; it is not the same task as running a complete Checkmk monitoring site inside the cluster.
Confirm the Checkmk edition, server version and supported Kubernetes range before selecting collector versions. The documentation calls out privileged host visibility and runtime-socket differences on some distributions, so review those permissions explicitly. Plan how the monitoring site reaches the API and collector endpoints without exposing them publicly. During migration, compare node inventory, workload metadata and resource-usage signals, and verify alert state transitions with a controlled workload change. Preserve site configuration and credentials independently of collector pods. Avoid assuming the old Nagios, wiki or graphing-component inventory remains the current architecture; use the edition’s documentation for capabilities and dashboard availability.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
The Check_MK is an open source based monitoring system. It fits almost any infrastructure. Basic element the Nagios and WATO GUI, and includes various modules: the NagVis, which is responsible for displaying the network topology, a PNP4Nagios, which collects the monitored system performance data in RRD format and displays them in the form of graphs and reports. It includes a DokuWiki system, which can be a great knowledge base. The monitoring system is able to monitor the resources and services of systems on the client side agent, API or SNMP.
The main function of a monitoring system is the status checking, the dashboard-based visualization, and change-based notification.
Features of the Check_MK:
- Extensive, deep and customizable monitoring with agent, API or SNMP;
- it ensures the integrity and confidentiality;
- able to synchronize with an NTP server;
- monitoring relatively easily managed through a Web Administration Tool (WATO);
- the monitored performance data is stored in a standard RRD format. and the ability to prepare reports;
there’s dashboard, which provides a summary presentation of the state; - the ability to display the logical network topology;
- it combines a physically separate, but logically related service;
- if a Syslog event occurs, then automatically responds with an action, and it can be controlled from the command line;
- capable of real-time alarms with e-mail or SMS server;
- easy backup and restore;
- role-based user management, LDAP-based user authentication (including Active Directory and eDirectory), and local user authentication;
- not affect the monitoring system and the monitored systems operation;
- able to read the Nagios plugins to facilitate the eventual migration.
Sources & further reading
Spotted something that needs another look?
Help improve this page →