Multiple clusters in single kube config file

The OpsLogix Kubernetes Management Pack monitors one cluster per kube config file. A single file that contains multiple clusters is not supported and will typically result in either a failed connection test or only one of the clusters being monitored.

Symptoms

• The connection test fails with the error: "While parsing a block mapping, did not find expected key."
• The kube config file appears correct — no tab characters, consistent indentation, and a space after every colon — yet the test still fails.
• Alternatively, the connection succeeds, but only one of several expected clusters is discovered and monitored.

Cause

There are two separate issues when multiple clusters are placed in one file:

1. The Management Pack does not differentiate between clusters in a single file. When connecting, the collector always uses the cluster referenced by the current-context: entry. It does not choose a cluster based on the connection name you enter in SCOM. A file containing several clusters will therefore only ever monitor the one named in current-context:.
2. Merged config files are usually invalid YAML. Combined files are commonly created by pasting several config files one after another. This leaves the top-level keys — apiVersion:, kind:, clusters:, contexts:, users:, current-context:, preferences: — repeated once per cluster. Duplicated top-level keys are not valid YAML, which produces the "did not find expected key" parse error, even when the indentation and spacing are otherwise correct.

Resolution

Use one kube config file per cluster, and add each cluster as a separate connection in SCOM.

1. Split the combined file into individual files — one per cluster.
2. In each file, ensure every top-level key (apiVersion:, kind:, current-context:, etc.) appears only once.
3. Set current-context: in each file to that file's cluster.
4. Add each cluster as its own connection in SCOM, using its individual config file.

Correct single-cluster structure

# A valid file contains each top-level key exactly once.
apiVersion: v1
kind: Config

clusters:
  - cluster:
      certificate-authority-data: <...>
      server: https://your-cluster:443
    name: cluster1

contexts:
  - context:
      cluster: cluster1
      user: user1
    name: cluster1

current-context: cluster1

preferences: {}

users:
  - name: user1
    user:
      token: <...>