Version 104 of the Kubernetes PowerPack includes support for OpenShift users, updates to the "Kubernetes Token Entry" dashboard and updates to Dynamic Applications.
- Minimum Required SL1 Version: 10.2.0
Before You Install or Upgrade
Ensure that you are running version 10.2.0 or later of SL1 before installing "Kubernetes" PowerPack version 104.
For details on upgrading SL1, see the relevant SL1 Platform Release Notes.
In addition, before installing or upgrading the PowerPack, you must first import and install the Linux Base Pack PowerPack version 103 or later. The PowerPack leverages the Linux Base Pack PowerPack and will not work properly if it is not also installed.
If you are upgrading from version 101 to version 102 or later of the PowerPack, you must delete the version 101 dashboards on SL1. To do so, perform the following steps:
- Go to the Device Dashboards page (System > Customize > Device Dashboards).
- Search for "Kubernetes" in the Device Dashboard Name column.
- Select the checkbox for each Kubernetes dashboard.
- In the Select Actions drop-down field, select Delete Dashboards.
- Click the button.
- Click the button to confirm.
Installation and Upgrade Process
NOTE: If you are currently using the Dynamic Applications in this PowerPack to monitor devices, collection errors might occur for one or two polling cycles when installing a new version. To prevent collection errors during an upgrade, you can optionally disable collection for monitored devices before performing the following steps and re-enable collection after the upgrade.
If you are currently using the Dynamic Applications in this PowerPack to monitor devices, collection errors might occur for one or two polling cycles during the installation of a new version. To prevent collection errors during an upgrade, you can optionally disable collection for monitored devices before performing the following steps and re-enable collection after the upgrade.
To install this PowerPack:
- Search for and download the PowerPack from the PowerPacks page (Product Downloads > PowerPacks & SyncPacks) at the ScienceLogic Support Site.
- In SL1, go to the PowerPacks page (System > Manage > PowerPacks).
- Click the Actions menu and choose Import PowerPack. The Import PowerPack modal appears.
- Click PowerPack file from step 1. and navigate to the
- Select the PowerPack file and click . The PowerPack Installer modal displays a list of the PowerPack contents.
- Click PowerPack is added to the PowerPack Manager page. . The
NOTE: If you are upgrading from version 100 or greater of the Kubernetes PowerPack, install the DockerPowerPack version 102 or greater before upgrading, if you have not done so already.
For more information about using the PowerPack, see the Monitoring Windows Systems with PowerShell manual.
Included Features
This release includes the following features:
- Dynamic Applications to discover and monitor Kubernetes devices
- Device Classes for each of the Kubernetes devices the PowerPack can monitor
- Event Policies and corresponding alerts that are triggered when Kubernetes devices meet certain status criteria
- A Dashboard and Dashboard Widget that you must use to create Credentials for discovering Kubernetes devices
- An SSH/Key Credential that the Kubernetes Token Entry Dashboard uses as a template for creating additional SSH/Key Credentials for monitoring Kubernetes clusters
You must use the Kubernetes Token Entry Dashboard that is included in the PowerPack to create a master SSH/Key Credential, a node SSH/Key Credential, and a SOAP/XML Credential. By doing so, you can specify the Kubernetes device topology that you want to discover. For more information, see the Monitoring Kubernetes manual.
You must not edit the SSH/Key Credential that is included in the PowerPack.
- Run Book Action and Automation policies that do the following:
- Automatically create Kubernetes clusters whenever the ScienceLogic platform discovers a Kubernetes host
- Align Dynamic Applications from the Linux Base Pack PowerPack to Kubernetes nodes and report if a successful alignment has occurred to the ScienceLogic Data Collector or All-in-One Appliance
- Ensure that Namespaces (and their children) have a 1-hour vanishing timer, to properly reflect topology changes
Enhancements and Issues Addressed
The following enhancements and addressed issues are included this release of the "Kubernetes":
- The "silo_apps" library was updated to version 3.1.4.
- The "silo_kubernetes_api" content library was updated to use "silo_logs".
- The "silo_kubernetes_api" content library was updated for version 103.0.2.
- Support was added to the PowerPack for users with Kubernetes OpenShift clusters versions 4.8, 4.9, and 4.10.
The PowerPack can monitor OpenShift clusters, but if the cluster size exceeds resource limits, collection problems might occur. ScienceLogic recommends a cluster size of up to 100 namespaces and 100 controllers or less than 10 namespaces and up to 200 controllers. The maximum recommended number of namespaces is 100 and the maximum recommended number of controllers is 200.
When a cluster is using multiple CronJobs that can generate a high event flow, you can disable collection on the namespaces that the CronJobs are aligned to.
- Logging was updated to ensure that sensitive information in the credential is hidden.
- The poll frequency of the "Kubernetes: Events Configuration" Dynamic Application was updated to 10 minutes.
- The following updates were made to the "Kubernetes Token Entry" dashboard:
- Users can now use the Collection Server PID field to select a specific Data Collector to use during discovery. (Support Case: 00219123; JIRA ID: SOL-17280)
- Users can now use the Timeout field to set a timeout value for the credential.
- Support was added for the following API versions:
- 118
- 119
- 120
- 121
- 122
- 123
-
The "Kubernetes: Pod Performance (Node)" Dynamic Application was updated to address an issue in which it would appear to continue to collect data after a node was deleted.
- An issue was addressed in which long the execution time of the "Kubernetes: Controller Discovery" Dynamic Application was causing SIGTERMs. (Support Case: 00252953; JIRA ID: SOL-19148)
-
An issue was addressed which the "Kubernetes: Cluster Creation" Run Book Automation failed to create a virtual device when another discovered virtual device had the same name of the Kubernetes cluster.
-
An issue was addressed in which a credential could not be created or edited when using the Kubernetes Token Entry Dashboard in SL1 version 11.2.0
Known Issues
The following known issues affect version 104 of the Kubernetes PowerPack:
- In systems in which a Kubernetes cluster is deleted or shut down, errors and exceptions may continue to appear in system and device logs. If your cluster has been deleted, you can disable data collection to stop the creation of more system log exceptions.
- Some deployments of OpenShift include an "Openshift- Marketplace" Namespace. If your instance includes this Namespace, you should disable the "Kubernetes: Events Configuration" Dynamic Application to avoid SIGTERMs.
- Some controllers are effected by a bug when discovering controllers. This bug can cause flapping between Available and Unavailable which can cause exceptions or generates a 15 minute gap in performance data collection on the controller. This issue will be addressed in a future version of the PowerPack.
- Recommended cluster size is based on CPU usage. The recommended size does not reach 100% CPU usage. This issue will be addressed in a future version of the PowerPack. If you want to monitor a cluster that exceeds the recommended size, follow these recommendations based on a four core collector unit with 32 GB of ram memory and 150 GB of hard drive:
- Recommeded: 100 namespaces or less and 100 controllers or 10 namespaces and up to 200 controllers
- Low Risk of SIGTERMs: 100 namespaces and 200 controllers
- Medium Risk of SIGTERMs: 150 namespaces and 100 to 150 controllers
- High Risk of SIGTERMs: 180 namespaces and 100 controllers
- Confirmed SIGTERMs: 200 namespaces and 200 or more controllers
When determining the amount of resources, consider the current size of the cluster and the possible risk of SIGTERMs during nightly discovery at "0:00 GMT".