Skip to content

Multi cluster

Chainsaw supports testing against multiple clusters.

To use a specific cluster in a test (or test step) you will need to register the cluster either using the config file or using command line flags.

Configuration

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Configuration
metadata:
  name: custom-config
spec:
  # ...
  clusters:
    cluster-1:
      kubeconfig: /path/to/kubeconfig-1
      context: context-name
    cluster-2:
      kubeconfig: /path/to/kubeconfig-2
      context: context-name
  # ...

Flag

The --cluster flag can appear multiple times and is expected to come in the following format --cluster cluster-name=/path/to/kubeconfig[:context-name].

chainsaw test                                               \
    --cluster cluster-1=/path/to/kubeconfig-1               \
    --cluster cluster-2=/path/to/kubeconfig-2:context-name

Usage

Once registered, a cluster can be specified at the test, step or operation level. If specified at multiple levels, the most granular one is selected, effectively overriding the cluster specified at higher levels.

Specifying cluster at the test level

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  # all steps and operations will be executed against the
  # cluster specified below (unless overridden)
  cluster: cluster-1
  steps:
  - try:
    # ...
    - assert:
        resource:
          apiVersion: v1
          kind: Deployment
          metadata:
            name: foo
          spec:
            (replicas > 3): true
    # ...

Specifying cluster at the step level

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  steps:
  - # all operations will be executed against the
    # cluster specified below (unless overridden)
    cluster: cluster-1
    try:
    # ...
    - assert:
        resource:
          apiVersion: v1
          kind: Deployment
          metadata:
            name: foo
          spec:
            (replicas > 3): true
    # ...

Specifying cluster at the operation level

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  steps:
  - try:
    # ...
    - assert:
        # operation will be executed against the
        # cluster specified below
        cluster: cluster-1
        resource:
          apiVersion: v1
          kind: Deployment
          metadata:
            name: foo
          spec:
            (replicas > 3): true
    # ...

$client binding

When a cluster is specified (whatever the test, step or operation level), the $client binding visible in operation expressions is always the Kubernetes client corresponding to the configured cluster.

In the example below, $client binding is a client to the configured cluster-1.

$client binding

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  steps:
  - try:
    # ...
    - assert:
        # operation will be executed against the
        # cluster specified below
        cluster: cluster-1
        resource:
          resource:
            (x_k8s_list($client, 'v1', 'Node')):
                (length(@)): 1
    # ...

KUBECONFIG in scripts and commands

When a cluster is specified (whatever the test, step or operation level), a temporary KUBECONFIG is automatically created and the KUBECONFIG is set to this temporary file for every command and script operation.

This way command and script operations are executed in the context of the configured cluster.

Temporary KUBECONFIG

The default KUBECONFIG you usually observe in your local shell will be different in script and command operations.

Temporary KUBECONFIG

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  steps:
  - try:
    # ...
    - script:
        # operation will be executed against the
        # cluster specified below
        cluster: cluster-1
        # the kubectl command below will use a 
        # KUBECONFIG environment variable pointing
        # to a temporary kubeconfig file configured
        # for the specified cluster
        content: kubectl get pods
    # ...