Attach an existing MKE cluster to a vSphere-based management cluster

Available since 2.25.2

Using the Container Cloud web UI, you can attach an existing Mirantis Kubernetes Engine (MKE) cluster that is not deployed by Container Cloud to a vSphere-based management cluster. This feature allows for a detailed visualization of all your MKE clusters in one place including cluster health, capacity, and usage.

Supported MKE versions for attachment

Mirantis supports two MKE minor release series for MKE cluster attachment: 3.5.x and 3.6.x with two MKE patch releases in each series. Each MKE patch release is linked to a dedicated Cluster release in Container Cloud. The supported MKE versions for a cluster attachment are defined in Compatibility matrix of component versions.

Note

Attachment of MKE clusters is tested on Ubuntu 20.04.

Features and limitations

The following table describes the main features and limitations of an existing MKE cluster attached to Container Cloud:

Features

Limitations

  • Visualize vital cluster details in the Container Cloud web UI such as cluster health, capacity, and usage.

  • Manage cluster permissions.

  • Enable cluster logging, monitoring, and alerting using StackLight. For details, see StackLight requirements for an MKE attached cluster and the below procedure.

  • Update the cluster to the latest available Cluster release dedicated for cluster attachment, when available. For details, see Update a managed cluster.

  • Enable maintenance mode on the cluster and its machines to perform operating system configuration or node reboot without affecting the workloads. For details, see Enable cluster and machine maintenance mode.

  • No control over the cluster infrastructure. Container Cloud controls Keycloak integration, reflects the cluster nodes as Machine objects, and provides cluster updates.

  • No possibility to add or remove machines, manage operating system configuration (for example, Docker upgrade).

  • The proxy and cache feature is not supported.

  • Nodes of the attached cluster do not contain LCM Agent.

Caution

An MKE cluster can be attached to only one management cluster. Attachment of a Container Cloud-based MKE cluster to another management cluster is not supported.

Attach an existing MKE cluster

  1. Log in to the Container Cloud web UI with the m:kaas:namespace@operator or m:kaas:namespace@writer permissions.

  2. Switch to the required project using the Switch Project action icon located on top of the main left-side navigation panel.

  3. In the Clusters tab, expand the Create Cluster menu and click Attach Existing MKE Cluster.

  4. In the wizard that opens, fill out the form with the following parameters as required:

    1. Configure general settings:

      • Cluster Name - specify the cluster name

      • Region - select vSphere

      Note

      The Region parameter was removed in Container Cloud 2.26.0.

    2. Upload the MKE client bundle using upload MKE client bundle or fill in the fields manually.

      To download the MKE client bundle, refer to MKE user access: Download client certificates.

    3. For StackLight, make sure that your deployment meets the requirements described in StackLight requirements for an MKE attached cluster.

    4. Configure StackLight:

      Section

      Parameter name

      Description

      StackLight

      Enable Monitoring

      Selected by default. Deselect to skip StackLight deployment. You can also enable, disable, or configure StackLight parameters after deploying a managed cluster. For details, see Change a cluster configuration or Configure StackLight.

      Enable Logging

      Select to deploy the StackLight logging stack.

      For details about the logging components, see Deployment architecture.

      Note

      The logging mechanism performance depends on the cluster log load. In case of a high load, you may need to increase the default resource requests and limits for fluentdLogs. For details, see StackLight configuration parameters: Resource limits.

      HA Mode

      Select to enable StackLight monitoring in the HA mode. For the differences between HA and non-HA modes, see Deployment architecture.

      StackLight Default Logs Severity Level

      Log severity (verbosity) level for all StackLight components. The default value for this parameter is Default component log level that respects original defaults of each StackLight component. For details about severity levels, see Log verbosity.

      StackLight Component Logs Severity Level

      The severity level of logs for a specific StackLight component that overrides the value of the StackLight Default Logs Severity Level parameter. For details about severity levels, see Log verbosity.

      Expand the drop-down menu for a specific component to display its list of available log levels.

      OpenSearch

      Logstash Retention Time

      Skip this parameter since Container Cloud 2.26.0 (17.1.0, 16.1.0). It was removed from the code base and will be removed from the web UI in one of the following releases.

      Available if you select Enable Logging. Specifies the logstash-* index retention time.

      Events Retention Time

      Available if you select Enable Logging. Specifies the kubernetes_events-* index retention time.

      Notifications Retention

      Available if you select Enable Logging. Specifies the notification-* index retention time and is used for Mirantis OpenStack for Kubernetes.

      Persistent Volume Claim Size

      Available if you select Enable Logging. The OpenSearch persistent volume claim size.

      Collected Logs Severity Level

      Available if you select Enable Logging. The minimum severity of all Container Cloud components logs collected in OpenSearch. For details about severity levels, see Logging.

      Prometheus

      Retention Time

      The Prometheus database retention period.

      Retention Size

      The Prometheus database retention size.

      Persistent Volume Claim Size

      The Prometheus persistent volume claim size.

      Enable Watchdog Alert

      Select to enable the Watchdog alert that fires as long as the entire alerting pipeline is functional.

      Custom Alerts

      Specify alerting rules for new custom alerts or upload a YAML file in the following exemplary format:

      - alert: HighErrorRate
        expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
        for: 10m
        labels:
          severity: page
        annotations:
          summary: High request latency
      

      For details, see Official Prometheus documentation: Alerting rules. For the list of the predefined StackLight alerts, see Operations Guide: Available StackLight alerts.

      StackLight Email Alerts

      Enable Email Alerts

      Select to enable the StackLight email alerts.

      Send Resolved

      Select to enable notifications about resolved StackLight alerts.

      Require TLS

      Select to enable transmitting emails through TLS.

      Email alerts configuration for StackLight

      Fill out the following email alerts parameters as required:

      • To - the email address to send notifications to.

      • From - the sender address.

      • SmartHost - the SMTP host through which the emails are sent.

      • Authentication username - the SMTP user name.

      • Authentication password - the SMTP password.

      • Authentication identity - the SMTP identity.

      • Authentication secret - the SMTP secret.

      StackLight Slack Alerts

      Enable Slack alerts

      Select to enable the StackLight Slack alerts.

      Send Resolved

      Select to enable notifications about resolved StackLight alerts.

      Slack alerts configuration for StackLight

      Fill out the following Slack alerts parameters as required:

      • API URL - The Slack webhook URL.

      • Channel - The channel to send notifications to, for example, #channel-for-alerts.

      StackLight optional settings

      Enable Reference Application

      Available since Container Cloud 2.22.0. Enables Reference Application that is a small microservice application that enables workload monitoring on non-MOSK managed clusters.

      Note

      For the feature support on MOSK deployments, refer to MOSK documentation: Deploy RefApp using automation tools.

      Disabled by default. You can also enable this option after deployment from the Configure cluster menu.

  5. Click Create.

    To monitor the cluster readiness, hover over the status icon of a specific cluster in the Status column of the Clusters page.

    Once the orange blinking status icon becomes green and Ready, the cluster deployment or update is complete.

    You can monitor live deployment status of the following cluster components:

    Component

    Description

    Bastion

    For the OpenStack-based management clusters, the Bastion node IP address status that confirms the Bastion node creation

    Helm

    Installation or upgrade status of all Helm releases

    Kubelet

    Readiness of the node in a Kubernetes cluster, as reported by kubelet

    Kubernetes

    Readiness of all requested Kubernetes objects

    Nodes

    Equality of the requested nodes number in the cluster to the number of nodes having the Ready LCM status

    OIDC

    Readiness of the cluster OIDC configuration

    StackLight

    Health of all StackLight-related objects in a Kubernetes cluster

    Swarm

    Readiness of all nodes in a Docker Swarm cluster

    LoadBalancer

    Readiness of the Kubernetes API load balancer

    ProviderInstance

    Readiness of all machines in the underlying infrastructure (virtual or bare metal, depending on the provider type)

    Graceful Reboot

    Readiness of a cluster during a scheduled graceful reboot, available since Cluster releases 15.0.1 and 14.0.0.

    Infrastructure Status

    Available since Container Cloud 2.25.0 for bare metal and OpenStack providers. Readiness of the following cluster components:

    • Bare metal: the MetalLBConfig object along with MetalLB and DHCP subnets.

    • OpenStack: cluster network, routers, load balancers, and Bastion along with their ports and floating IPs.

    LCM Operation

    Available since Container Cloud 2.26.0 (Cluster releases 17.1.0 and 16.1.0). Health of all LCM operations on the cluster and its machines.

    For the history of a cluster deployment or update, refer to Inspect the history of a cluster and machine deployment or update.

  6. For StackLight, add the StackLight label to worker nodes. For details, see Node Labels in Create a machine using web UI.

    1. On the Machines page, click the More action icon in the last column of the required machine field and select Configure machine.

    2. In Node Labels, select StackLight.

Caution

To detach an MKE cluster, use the Detach button in the cluster menu of the Container Cloud web UI. Do not delete the cluster machines using the cloud provider tools directly to prevent issues with cluster detachment or cleaning of machines resources manually.

Note

Before Container Cloud 2.26.0, to detach an MKE cluster, use the Delete button in the cluster menu.