Skip to content

Container Estate

Purpose

Container Estate is the one place in Clarity Transform where the discovered container estate is presented as a whole: clusters, nodes, namespaces, workloads and services across OpenShift and Nutanix NKP, with the breakdowns that show its shape and a count of workloads in a move group. The on-screen subtitle reads: "Discovered OpenShift and Nutanix NKP clusters, workloads and capacity".

It is a read-only dashboard: nothing on it changes data. It summarises the container records in the CMDB, which the OpenShift, OCM and Nutanix NKP integrations fill in, without opening each container grid. The page loads its figures when it opens. Reload the page to see later changes.

Where to find it

Discover → Data Analysis → Container Estate. The page header is Container Estate.

What you see

Cards

  • CLUSTERS: with the number of nodes ("N nodes").
  • NAMESPACES
  • WORKLOADS: with the number in a move group ("N in a move group").
  • SERVICES: with the number of Helm releases and CRDs ("N Helm releases, N CRDs"). A Helm release is an application installed with the Helm package manager. A CRD (custom resource definition) adds a new kind of object to a cluster.

If the figures cannot be loaded, the cards show "-" with "unavailable" underneath, an error message appears, and the table reads "Failed to load container estate data." This is a load failure, not an empty estate. Reload the page.

Charts

  • Workloads by Namespace
  • Workloads by Kind
  • Workloads by Platform
  • Workloads by Image Registry

Workloads by Namespace and Workloads by Image Registry are horizontal bar charts with the largest at the top. Workloads by Kind and Workloads by Platform are doughnuts. Hover over a chart for its values.

Each chart has icons at its top right: Restore, which resets the chart's view (it does not reload the data), and Save as Image, which downloads the chart as a picture. The bar charts also have Zoom and Zoom Reset icons.

Workloads by Namespace does not show every namespace in a large estate. Use the NAMESPACES card for the total.

Cluster Capacity and Commitment

A table with one row per cluster and the columns Cluster, Platform, Nodes, Namespaces, Workloads, vCPU, CPU req / lim, Memory (GB) and Mem req / lim (GB).

  • Platform gives the platform and, where it was discovered, its version.
  • CPU req / lim and Mem req / lim (GB) give the total resource requests, then the total limits, of the cluster's workloads, as "requests / limits". A request is what a workload reserves; a limit is the most it may use.
  • Figures are rounded to two decimal places. A "-" means the value was not discovered.

Compare the requests with vCPU and Memory (GB) to see how committed each cluster is. If no clusters have been discovered, the table reads "No container clusters discovered yet."

How to

Check the size of the container estate

  1. Go to Discover → Data Analysis → Container Estate.
  2. Read the CLUSTERS, NAMESPACES, WORKLOADS and SERVICES cards. Compare the cluster count with the clusters you expected to be discovered.
  3. In Cluster Capacity and Commitment, read each cluster's Platform, Nodes, vCPU and Memory (GB), and the requests and limits against them.

See where the workloads sit

  1. On the Container Estate page, read Workloads by Namespace, then Workloads by Kind.
  2. Read Workloads by Image Registry to see which registries the workloads pull their images from.

Check move group coverage

  1. On the Container Estate page, read the WORKLOADS card. Its second line gives the number of workloads in a move group.
  2. To place more workloads in move groups, go to Move Groups.

View a container object's manifest

The manifest of a discovered container object is kept on its CMDB record.

  1. Go to Discover → CMDB and select the Container Workload, Container Node, Container Namespace, Container Service or Container CRD card.
  2. Select the record's Name. Its edit form opens.
  3. Select the button that views the manifest, or the one that views the spec JSON (for a CRD, its schema). A read-only viewer opens, showing the object's kind and name (and, for the manifest, its namespace) above the formatted JSON.
  4. To copy the text, use the viewer's copy button.
  5. Close the viewer with its close button, the Esc key, or by selecting outside it. Then select Cancel to close the form without saving.

The viewer finds the manifest from the record's cluster, kind, namespace and name as they stand in the form, so do not change them before you open it.

The buttons are disabled on the Create new entry form, with the hint "Manifest and spec become available after this record is discovered."

The viewer can show these messages instead of a manifest:

Message Meaning
"No manifest is stored for this object. Manifests are captured only for supported resource kinds and require read access during discovery." Discovery did not capture a manifest for this object. Check the kind is supported and that the integration's account can read it.
"No data was captured for this object." The record's spec JSON (or a CRD's schema) is empty.
"Not enough information to locate a manifest for this object." The form has no cluster, kind or name.
"The manifest could not be loaded. Please try again." The request failed. Try again.
  • CMDB: the Container Cluster, Container Namespace, Container Node, Container Service and Container Workload grids behind this page.
  • OpenShift, Nutanix NKP and OCM: the integrations that discover container clusters.
  • Container Readiness: readiness of namespaces for migration.
  • Move Groups: where workloads are placed in move groups.