Skip to content
English
Submit a support ticket
Back to www.opslogix.com
  • There are no suggestions because the search field is empty.

Kubernetes Management Pack upgrade guide

How to upgrade the Opslogix Kubernetes Management Pack to V26.11.4546.0, and what changes after the upgrade

Applies to: Opslogix Kubernetes Management Pack (upgrade to V26.11.4546.0 from any earlier version)
Last updated: November 2026 · Latest version: 26.11.4546.0

See also: Quick start guide · Release notes · List of rules and monitors

This guide describes how to upgrade the Opslogix Kubernetes Management Pack to V26.11.4546.0. Your clusters, license assignments and overrides stay in place. Plan about 15 minutes, plus an hour before all new objects are discovered.

Before you upgrade

Check the permissions of the account in the kube config of each cluster. V26.11.4546.0 reads more resources than earlier versions:

  • get on nodes/proxy, to read disk usage from the kubelet of each node.
  • list on persistentvolumeclaims, storageclasses, endpointslices (API group discovery.k8s.io), pods, deployments, statefulsets and events, for the persistent volume claim and service monitors.

If you created the account as described in How to create a Kubernetes monitoring account or Creating a OpenShift or OKD Monitoring Service Account, its read-only cluster role already grants all of these and you don't have to change anything. If you use a narrower role, add them before the upgrade: without them the new monitors collect no data, the Kubernetes Service Endpoints monitor turns Warning because it cannot read the endpoint slices, and failed volume resizes and load balancers are only reported as Warning because the events cannot be read. The rest of the monitoring keeps working.

Upgrade steps

  1. Download V26.11.4546.0 from the Customer Portal and unzip it.
  2. In the Operations console, go to Administration > Management Packs, choose Import Management Packs, Add from disk, and select all management packs from the download. Click Install.
  3. Upgrade the collector. Go to Administration > OpsLogix MP Configuration > Kubernetes MP Configuration, open one of your clusters and click Test Configuration. This runs the task "OpsLogix Deploy Kubernetes Collector Task" on all members of the resource pool of the cluster, which upgrades the collector to the version in the management pack. Repeat this for clusters that use another resource pool. If you changed the collector settings in appsettings.json, set them again: the upgrade replaces the file.
  4. Restart the Microsoft Monitoring Agent (HealthService) on all members of the resource pool, so they load the new version of the monitoring modules. Until the restart, new monitors can stay without data.
  5. Check the result after about an hour: persistent volume claims appear in the new Persistent Volume Claims folder, services show their type, ports and selector, and the performance views show disk usage of nodes and pods.

What changes when you upgrade to V26.11.4546.0

  • New monitors raise alerts for problems that already exist. Expect alerts right after the upgrade for services without ready endpoints, nodes or volumes that are almost full, and persistent volume claims that are pending or lost. See How service endpoint and load balancer monitoring works, How persistent volume claim monitoring works and How disk usage monitoring works for Kubernetes nodes and pods.
  • Clusters without a load balancer controller. On a cluster without a cloud provider integration, MetalLB or a similar controller, services of type LoadBalancer never get an external address, so the Kubernetes Service Load Balancer monitor turns Warning. If that is expected, disable the monitor for those services or that cluster with an override.
  • Pod CPU and memory utilization is now a percentage of the pod limits. Before, the percentage was calculated against the node capacity, so it stayed low even when a pod was about to be killed for running out of memory. Pods that run close to their limits now show a high percentage and can raise alerts that they did not raise before. Pods without limits are still compared with the node capacity.
  • Pod state monitors keep working while a pod is not scheduled. Before, one pod that was waiting to be scheduled stopped the Pod Phase and pod condition monitors for all pods in the cluster.
  • Cluster groups. The group "All Kubernetes Objects For Cluster [name]" that the configuration dashboard creates includes persistent volume claims only for clusters added after the upgrade. Claims of existing clusters are monitored, but are not members of that group. The All Kubernetes Objects group does include them.