We have added more features to this project, and besides the examples, the documentation is missing.

It would be good to start with:

• documenting the existing APIs.
• describes how this extension wraps the k8s go client library.

This change set introduces helpers to facilitate common tasks when setting tests in Kubernetes.

It also introduces a set of structured operations that work on typed objects (e.g. Pods) as opposed to unstructured operations that work on generic objects. These structured operations are intended for the helpers, to avoid the complexity of manipulating generic objects in go.

I've added pkgs to work with Persistent Volumes and Persistent Volume Claims.

With the PV example I only guesstimated in the apply-get-delete version because in our cluster we're not allowed to create PVs directly. I hope it works, but if anyone has a cluster where they could try it out I'd be happy if you tested it out and edited the YAML in case it doesn't work :)

I have added Apply function to Kubernetes classes. This function tries to parse a provided YAML string and if the type of the parsed object is the same as the class, the function creates the object on the Kubernetes server.

I have added this change because I could not figure out how to pass Kubernetes objects to the Create function through javascript.

After running the xk6-kubernetes example script add-ephemeral.js, I noticed an error on stout:

ERRO[0002] GoError: the server could not find the requested resource
running at reflect.methodValueCall (native)

The pod gets created, though. so the functionality of the script works as expected. This error just makes it seem like there's a failure somewhere...

When I try to kill (kill-pod.js) that pod created with the add-ephemeral.js script, I also get the error message. The pod does get killed.

The create-pod.js script does not produce this error message. Killing that pod (with kill-pod.js) comes back successful as well (no error message).

While running the basic list-pods script against a cluster in GCP, I encounter the following error:

ERRO[0000] no Auth Provider found for name "gcp"
        at file:///home/vw/dev/k6/scripts/list-pods.js:5:21(4)
        at native  executor=per-vu-iterations scenario=default source=stacktrace

From my understanding, the expected action is to read from the kubeconfig filepath provided (or take from the default path).

Is the default incorrect, or does the documentation need to be updated differently?

Add function to Pods for creating an ephemeral container in a running pod. Also added a function for creating a pod to facilitate testing.

Note: tested with K8s cluster 1.23.x. Previous versions may not work or may need enabling ephemeral containers feature gate

closes #30

I am trying to run test with kubernetes version v1.19.13 using most of example scripts.But I don't think it's working. For an example, get-pod.js - when I run it from local and pod not present in namespace,the test should display: pod not found

Fixes #82

NOTE: The use of theApply method in the example script will fail if the resource already exists. This has been corrected by #81 which is yet to merge.

Self-explanatory, I think 😄

The error:

ERRO[0003] GoError: pods "httpbin" already exists
Run     at reflect.methodValueCall (native)
base    at setup (file:///Users/dgzlopes/go/src/github.com/grafana/xk6-disruptor/examples/httpbin/disrupt-pod.js:18:14(7))
disrupt at native  hint="script exception"

I have the feeling this shouldn't fail. Same way, while using kubectl, it doesn't fail if the resources already exist.

A very basic requirement when executing chaos tests on deployments is to act on one of replicas (for example, kill it). Even when it is possible to obtain the list of replicas by listing all pods in a namespace and filtering those that matches the label selector of the deployment, this in inconvenient.

Therefore, it would be convenient to have a function that, given a deployment, returns the existing list of pods. This function could optionally accept some flag(s) for common field selectors, such as state (e.g. to filter-out non running replicas)

Presently the Delete function does not allow the specification of DeleteOptions. This options are important in certain use cases, as for example forcing the deletion by setting the gracePeriodSeconds to 0, or changing the propagationPolicy.

Presently the Apply method provided by the generic API is implemented as a Create from a yaml file. This is not consistent with the experience that users may have with thekubectl apply command that allows both creating new resources or modifying existing resources.

Starting with v1.25 the dynamic client now offers an Apply method which implements the desired functionality, allowing both the creation or the modification of resources.

Therefore, it would be convenient for the sake of consistency and convenience to re-implement the Apply method in the generic API using this newly provided Apply method in the dynamic client.

When setting the resources for a test, it is a common case that after deployment an application as a Deployment, the test must wait until all the replicas are ready. This is a simple tasks, but having a helper function will prevent repeating the code across tests.

The main use case for the xk6-kubernetes extension is facilitating the setup of tests, by providing a simple API for creating Kubernetes resources such as secrets, pods, services and others required for running a test application.

When running multiple concurrent tests, it is convenient to isolate tests by using different namespaces when creating the resources needed by the tests. Moreover, it is convenient to use randomly generated namespaces for each test, to prevent interferences with other instances of the same tests running concurrently or that run previously and was not properly teared down.

This means that of such test scripts must include a sequence of code similar to the example below:

import { Kubernetes } from 'k6/x/kubernetes'
import { randomString } from 'https://jslib.k6.io/k6-utils/1.2.0/index.js';

const namespace = randomString(8)
       
const nsObj = {
    apiVersion: "v1",
    kind: "Namespace",
    metadata: {
        name: "test-ns"
    }
}


export  function setup() {
  const k8s = new Kubernetes()
  k8s.create(nsObj)
}

Being this a very common use case, In order to prevent this redundancy of code on each test, it will be convenient to provide a helper function that creates a new namespace with a random name and return its name, reducing the above sequence to this show below:

import { Kubernetes } from 'k6/x/kubernetes'


export function setup() {
  const k8s = new Kubernetes()
  namespace = k8s.randomNamespace()
}

The xk6-kubernetes extension ~~was initially developed with the intention of~~ has been used for chaos experiments, providing basic functionalities such as deleting resources (e.g. namespaces, secrets) and running work loads (for example, jobs). It also provided some other basic functions for creating resources but adding little or no additional abstractions over the native k8s api.

The functions provided by xk6-kubernetes can also be used when setting up tests. However, some common tasks such as exposing a deployment as a service require considerable boiler plate code and can became tedious to program.

At the same time, as the requirements for running chaos experiments has become more complex, some specialized functions has been added, such as attaching ephemeral containers to running pods, or executing commands in a container.

It seems clear that the current design of xk6-kubernetes mixes functions that are too generic for been useful when setting up tests or too specialized for been in a general purpose k8s extension. Therefore the following changes are proposed:

1. Focus on providing helpers that abstract common tasks such as the proposed in #62
2. Cover other requirements by providing generic apply functions for creating resources using yaml definitions.
3. Move specialized functionality introduced to support chaos experiments (ephemeral containers, command execution) to xk6-chaos

Regarding the generic apply method, as handling inline yaml can be cumbersome (in particular if we want to substitute certain fields using variables) other alternatives can be explored:

• rendering inline yaml using inline text templates (similar to using helm charts)
• generating yaml using tools such as kustomize, embedding this tool(s) into the library to prevent dependencies with external binaries in the test environment.

Edit: The generic interface could also be provided by using usinga generic golang client that handles resources as generic structs which should be easily mapped to javascript objects.

One potential benefit of using a generic apply method is the possibility of removing the dependencies to many of the k8s api packages, reducing the size of the extension.

https://github.com/grafana/xk6-kubernetes/issues/66#tasklist-block-b64ef893-bb0a-47f6-ae2e-2cb31de67c10