StackLight requirements for an MKE attached cluster¶
Available since 2.25.2
During attachment of a Mirantis Kubernetes Engine (MKE) cluster that is not deployed by Container Cloud to a vSphere-based management cluster, you can add StackLight as the logging, monitoring, and alerting solution. In this scenario, your cluster must satisfy several requirements that primarily involve alignment of cluster resources with specific StackLight settings.
General requirements¶
While planning the attachment of an existing MKE cluster that is not deployed by Container Cloud to a vSphere-based management cluster, consider the following general requirements for StackLight:
For StackLight in non-HA mode, make sure that you have the default storage class configured on the MKE cluster being attached. To select and configure a persistent storage for StackLight, refer to MKE documentation: Persistent Kubernetes storage.
Allow the StackLight monitoring agents (Node Exporter and Fluentd) to schedule on the MKE manager and MSR nodes as described in Allow services deployment on Kubernetes MKE manager or MSR nodes.
Make sure that StackLight can create
LoadBalancer
Services in the cluster to externally expose StackLight web UIs.
Note
Attachment of MKE clusters is tested on Ubuntu 20.04.
Requirements for cluster size¶
While planning the attachment of an existing MKE cluster that is not deployed by Container Cloud to a vSphere-based management cluster, consider the cluster size requirements for StackLight. Depending on the following specific StackLight HA and logging settings, use the example size guidelines below:
The non-HA mode - StackLight services are installed on a minimum of one node with the StackLight label (StackLight nodes) with no redundancy using Persistent Volumes (PVs) from the default storage class to store data. Metric collection agents are installed on each node (Other nodes).
The HA mode - StackLight services are installed on a minimum of three nodes with the StackLight label (StackLight nodes) with redundancy using PVs provided by Local Volume Provisioner to store data. Metric collection agents are installed on each node (Other nodes).
Logging enabled - the Enable logging option is turned on, which enables the OpenSearch cluster to store infrastructure logs.
Logging disabled - the Enable logging option is turned off. In this case, StackLight will not install OpenSearch and will not collect infrastructure logs.
LoadBalancer
(LB) Services support is required to provide external access
to StackLight web UIs.
StackLight nodes 1 |
Other nodes |
Storage (PVs) |
LBs |
|
Non-HA (1-node example) |
|
|
|
5 |
HA (3-nodes example) |
|
|
|
5 |
StackLight nodes 1 |
Other nodes |
Storage (PVs) |
LBs |
|
Non-HA (1-node example) |
|
|
|
4 |
HA (3-nodes example) |
|
|
|
4 |
- 1(1,2)
In the non-HA mode, StackLight components are bound to the nodes labeled with the StackLight label. If there are no nodes labeled, StackLight components will be scheduled to all schedulable worker nodes until the StackLight label(s) are added. The requirements presented in the table for the non-HA mode are summarized requirements for all StackLight nodes.