Design

particle is basically a big glue program. Its aim is to create one interface to test kubernetes manifests, even when you use different tools. The steps are, more or less:

• Create a kubernetes cluster
• Lint your manifests
• Install dependencies for the manifests you're developing
• Install your manifests
• Test them
• Destroy the cluster

As you can see, those steps should be easily automatized. For doing so, there's some main concepts that you'll see mentioned in the documentation, that are core concepts for particle:

• driver
• provisioner
• verifier
• linter
• scenarios

Driver

The driver is the component that manages the kubernetes cluster. Its interface is comprised by:

• Create: It creates the cluster. With the kind driver, it executes kind create cluster.
• Destroy: It destroys the cluster. With the kind driver, it executes kind destroy cluster.

Provisioner

The provisioner is the component that manages the kubernetes manifests. Its interface is comprised by:

• Cleanup: It uninstalls all the kubernetes manifests. With the helm provisioner, it executes helm uninstall for both the dependencies and the main manifests.
• Dependency: It executes the steps that the prepare step needs. With the helm provisioner, it executes helm repo add.
• Prepare: It installs the dependencie's manifests. With the helm provisioner, it executes helm install for the dependencies.
• Converge: It installs the main manifests. With the helm provisioner, it executes helm install for the main manifests.

Verifier

The verifier it's not really a component as much as a "do what you need" section. That's because the verifying process it's really different from the previous steps. You'll want to create one cluster, but you'll might want to execute multiple verifiers.

For example, you'll might want to execute bats, goss, sonobuoy, ... There's multiple tools and you might want to execute them all, and you might want to execute them all. If particle tried to offer an API for all of them, it would act as a bottleneck.

For that reason, the verifier component just executes the commands that you pass to it through the configuration.

You may see examples here.

Linter

The linter it's not really a component as much as a "do what you need" section. That's because the linting process it's really different from the previous steps. You'll want to create one cluster, but you'll might want to execute multiple linters.

For example, you'll might want to execute yamllint, kubeval, OPA, ... There's multiple tools and you might want to execute them all, and you might want to execute them all. If particle tried to offer an API for all of them, it would act as a bottleneck.

For that reason, the linter component just executes the commands that you pass to it through the configuration.

You may see examples here.

Scenarios

The scenarios are a way of having multiple particle configurations. For example, you might want to have a scenario for your local development in which the driver is kind. But for your CI, you might want to have a different scenario, which would be making the driver be eks. (This is an example, since at the moment kind is the only supported driver.)

Flow diagram

When executing particle test, the flow diagram would be: