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:
(x_k8s_list($client, 'v1', 'Node')):
(length(items)): 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
# ...