Octopus Easy Mode - Kubernetes

Matthew CaspersonMarch 9, 2026 • 4 min read

In the previous post, you added a custom lifecycle to your project. In this post, you’ll create a mock Kubernetes deployment.

Prerequisites

• An Octopus Cloud account. If you don’t have one, you can sign up for a free trial.
• The Octopus AI Assistant Chrome extension. You can install it from the Chrome Web Store.

Creating the project

This example builds on the concepts introduced in previous posts to construct an end-to-end deployment solution to a mock Kubernetes cluster.

Paste the following prompt into the Octopus AI Assistant and run it:

Create a Kubernetes project called "K8s Web App", and then:
* Use client side apply in the Kubernetes step (the mock Kubernetes cluster only supports client side apply).
* Disable verification checks in the Kubernetes steps (the mock Kubernetes cluster doesn't support verification checks).
* Enable retries on the K8s deployment step.

---

Create a token account called "Mock Token".

---

Create a feed called "Docker Hub" pointing to "https://index.docker.io" using anonymous authentication.

---

Create a Kubernetes target with the tag "Kubernetes", the URL https://mockk8s.octopus.com, using the health check container image "octopusdeploy/worker-tools:6.5.0-ubuntu.22.04" from the "Docker Hub" feed, using the token account, and the "Hosted Ubuntu" worker pool.

This prompt creates a new project with a Kubernetes deployment step deploying a sample application to a mock Kubernetes server defined in a Kubernetes target. A deployment process defines how an application is deployed, while targets define where the application is deployed.

The mock Kubernetes server exposes just enough of the Kubernetes API to allow the deployment step to execute successfully, but it doesn’t actually create any Kubernetes resources. This allows you to test the deployment process without needing access to a real Kubernetes cluster.

All of these steps run in the Hosted Ubuntu worker pool provided as part of the Octopus cloud platform.

apiVersion: v1
kind: Config
current-context: local
clusters:
- name: default-cluster
  cluster:
    server: http://localhost:48080
users:
- name: default-user
  user:
    token: anything_will_work # the mock server accepts any token
contexts:
- name: local
  context:
    cluster: default-cluster
    user: default-user
    namespace: default

kubectl run nginx-test --image=nginx --restart=Never

kubectl get pods -A

You can now create a release and deploy it to the first environment. The Kubernetes deployment step deploys a Kubernetes deployment resource to the mock Kubernetes server. Of course, no actual Kubernetes resources are created, but Octopus interacts with the mock server as if it were a real Kubernetes API server.

You will notice that the sample Kubernetes project includes some additional steps. Specifically, it includes a step to scan the Software Bill of Materials (SBOM) associated with the sample project. The results of this scan show you if your deployment has any security vulnerabilities.

The security scan is executed daily in a dedicated environment called Security using a trigger. This means the SBOM scan result is updated to reflect any new vulnerabilities discovered after a production deployment.

Once the deployment is complete, the execution container is discarded, along with the mock server and any deployed resources.

What just happened?

You created a sample project with:

• A Kubernetes deployment step deploying raw YAML inside an execution container
• A manual intervention with step conditions to only run in the Production environment
• Using step conditions to exclude the deployment step from the Security environment
• A step to scan the SBOM associated with the sample application
• A trigger to rerun the security scan daily
• A Kubernetes target referencing the mock Kubernetes server

Matthew CaspersonPublished: March 9, 2026