Default Filtering for Kubernetes Resources
Last updated on 07 March, 2025In scenarios such as a new installation or a cache refresh, the entire Kubernetes cluster gets synchronized with the portal. This process results in a large number of devices being added to the cluster unnecessarily, adding strain to the system.
During the default installation, all resources are monitored by the lm-container
. However, to address the above-mentioned issue, the following resources will be either filtered or disabled from monitoring:
- Only critical resources will be enabled by default.
- Non-essential resources will be disabled or filtered, but customers can add them back to monitoring by updating the filter criteria in the Helm chart.
To optimize system performance and reduce unnecessary resource load, several default configurations will be applied to filter or disable specific resources, ensuring that only the essential components are actively monitored.
- Default Filtering of Ephemeral Resources: Ephemeral resources, such as Jobs, CronJobs, and pods created by CronJobs, will be filtered out by default to reduce unnecessary load. For example:
argus:
disableBatchingPods: "true"
Default filtering
- Disabled Monitoring of Kubernetes Resources: Resources like ConfigMaps and Secrets will be added to a list of disabled resources, preventing them from being monitored by default during cluster setup. For example:
argus:
monitoringMode: "Advanced"
monitoring: disable:
- configmaps
Resources Disabled for Monitoring by Default
Below is a list of Kubernetes resources that will be disabled by default but can be enabled if you choose:
- ResourceQuotas
- LimitRanges
- Roles
- RoleBindings
- NetworkPolicies
- ConfigMaps
- ClusterRoleBindings
- ClusterRoles
- PriorityClasses
- StorageClasses
- CronJobs
- Jobs
- Endpoints
- Secrets
- ServiceAccounts
Changes from Upgrading Helm Chart
In case of an upgrade from an older version of the lm-container
Helm chart to this version, the following applies:
- Default Filtering: If you have custom filters applied in the previous version, those filters will continue to take priority. The default filtering will not override their settings.
- Default Disabled Monitoring: If you had resources set for disabled monitoring in the older version, those configurations will remain in effect and will not be overwritten by the new defaults.
- Cross-Configuration for Filtering and Disabled Monitoring:
- If a customer had custom filters but had not configured disabled monitoring resources, the default list for disabled monitoring will be applied automatically.
- Conversely, if custom disabled monitoring resources were configured, the default filtering for resources will be applied.