The Get action allows us to retrieve objects from Kubernetes based on a YAML specification - the minimum we need to specify is the object type, the name of the object and the namespace that the object resides, for example the query kubectl get deployment controller --namespace metallb-system translates to the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: controller
  namespace: metallb-system

When the Kubernetes task runs the returned JSON object is accessible as part of the Task response object. This means that you can access properties of the requested object in subsequent tasks - e.g. to examine the number of deployments in the replica spec, I could access ${Stage0.Kubernetes.output.response.deployments.controller.spec.replicas}

The Create action allows us to create objects based on a YAML specification, and as is common accross all tasks you can use locally defined or Git sourced YAML definitions. There is also an option to Continue on conflict - if enabled, and the object you are trying to create already exists, then the Task will not fail the Pipeline but continue on to the next Task or Stage. This can be useful if you want to ensure an object exists but you are not sure if it already does - a common example would be creating a namespace.

You can also use YAML files with multiple documents, separated with --- to conform with YAML specifications - for example, the definition below creates two namespace:

Creating all the kubernetes resources with a single manifest file may be appropriate in some cases, however any failure of a single object creation will result in the whole task failing. If you need to respond to specific failures, or for ease of troubleshooting, it’s normally a better idea to split the objects into multiple tasks and manifests.

When this Create task is executed, the response JSON will include responses for each object creation (or associated failure)

The Apply action allows us to modify existing objects by applying an updated manifest YAML - this can be useful in a GitOps scenario when we are using Git as the single source of truth for an application. In this case when a YAML file is updated, a Git Trigger will start the pipeline and apply the updated YAML manifest to the existing object.

If we take the namespace from in the Create task, ns-01, and want to update the metadata with a label we can apply an updated manifest:

apiVersion: v1
kind: Namespace
metadata:
  name: ns-01
  labels:
    app: learn-code-stream

When this task executes, the response shows that the existing object has been updated with the new label:

The Delete action allows us to delete objects from Kubernetes based on a YAML specification - as with the Get action we need to specify enough information to identify the object we wish to delete. Most often, this is the object type, the name of the object and the namespace that the object resides - however to delete the namespace we created in the previous task we would use kubectl delete namespace ns-01, which translates to the following YAML:

apiVersion: v1
kind: Namespace
metadata:
  name: ns-01

When executed, the task succeeds if the object has been removed and fails if the deletion fails. The JSON output will reflect the new status:

The Rollback action relates to the management of deployment, statefulset and daemonset objects in kubernetes. Whenever the Pod template (.spec.template) properties for these objects are modified a rollout is triggered and a record of the previous state is recorded so that you can roll back to a previous state if required. The Rollback action allows you trigger a rollback to one of the previous five states and would typically be used to recover from a failed update to an existing deployment, statefulset or daemonset.