We are happy to announce the release of Icinga for Kubernetes v0.4.0! This is primarily a maintenance release that fixes a handful of long-standing bugs reported by the community, plus a small improvement to the Icinga Notifications integration.
What's New in v0.4.0
Cluster Identification & Notification Filtering in Icinga Notifications
When running multiple Kubernetes clusters against the same Icinga Notifications instance, events previously carried no information about which cluster they came from, making it hard to tell them apart, and impossible to filter or route notifications (like mail alerts) by cluster. Icinga for Kubernetes now sends a cluster identifier with every event and supports Icinga Notifications' rule-based event filtering, so you can filter and route notifications, based on which cluster an event came from. (#193, #195)
Requires Icinga Notifications v0.2.0 or newer if you use the notifications integration.
Bug Fixes
- Fixed database connections that use TLS with a CA certificate: the daemon previously ignored the configured TLS options entirely, causing
Access deniederrors instead of connecting. (#188, #189) - Fixed a panic on startup (
Observed a panic: "send on closed channel") that could crash the daemon while streaming relations into the database. (#142) - Fixed database insert failures (
Error 1406: Data too long for column) caused by very long container image names and long annotation values exceeding the size of their database columns. (#140, #196)
Get Started or Upgrade
Icinga for Kubernetes can be deployed either inside your Kubernetes cluster or outside the cluster as an external component. Check out all product details to learn more, and read the installation docs to get started quickly!
If you're upgrading from v0.3.0, update your packages, containers, or Helm charts based on your installation method. Schema changes will be deployed automatically.