mhausenblas / kboom Goto Github PK

Is it possibly to provide a different image than busybox on the cli?

Thanks for the nice work Michael!

After creating a service account named kboom-sa (whic is missing), I'm getting:

$ k logs kboom-trd2r
Error from server (BadRequest): container "kboom" in pod "kboom-trd2r" is waiting to start: trying and failing to pull image

seems ecr needs proper auth :-)

$ k describe pod kboom-trd2r
Failed to pull image "661776721573.dkr.ecr.us-east-2.amazonaws.com/kboom:latest": rpc 

error: code = Unknown desc = Error response from daemon: Get 

https://661776721573.dkr.ecr.us-east-2.amazonaws.com/v2/kboom/manifests/latest: no basic auth credentials

And

k create -f permissions.yaml

is needed.

Currently kboom using a polling approach to see if all Pods are up and running. We should switch to a watch based approach because of the following benefits:

• More fine granular start times (otherwise the granularity is limited to the polling interval)
• Less overhead on the control plane since we only get updates for Pods

In my experience with different Kubernetes services and BYO solutions there's disparity in between vendors and in-tree/out-of-tree drivers. It could be how effective PVC creation and subsequent PV binding perform. What also differs is how reliable attach/detach is during node drains or mass deployment, which sometimes fails altogether.

"Storage is hard"

... is the most used term in this space and it would therefor be very handy to use kboom as a sizing/discovery tool for what the optimal PVC/PV count is for a certain cluster and node size. Once you have an idea of where the boundaries are the cluster-admin can then divide volume counts across the projected namespaces and therefor make the cluster safer and won't run off a cliff blindly when not knowing where the ceiling is for the particular environment.

It think it would be great to have a capability to scale target over time, so that one can use the tool to determine an optimal scale for some given QPS and explore the relationship of QPS vs scale and where the limits are. This maybe already possible with a wrapper, but would be nice to see built-in automation for it.

Describe the bug

Installed as per the readme.

Running kboom in OpenShift fails due to the SSC

kubectl kboom generate --mode=scale:14 --load=pods:100

kubectl kboom results

2021/12/08 17:18:52 Can't create pod scale-sleeper-19: kubernetes api: Failure 403 pods "scale-sleeper-19" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000690000, 1000699999]]

To Reproduce

OpenShift 4.7

Expected behavior
Successful run

Additional context

OpenShift uses a security context, which is what is being referenced.
https://docs.openshift.com/container-platform/4.7/cicd/pipelines/using-pods-in-a-privileged-security-context.html

I'm occasionally getting spurious json decode errors when trying to run larger numbers of pods.

kubectl kboom generate --mode=scale:60 --load=pods:1000

<snip>
2019/04/27 04:10:35 Can't create pod scale-sleeper-936: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-1176: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-767: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-275: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-896: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-160: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-376: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-130: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-921: decode error status 429: decode json: invalid character 'T' looking for beginning of value
2019/04/27 04:10:35 Can't create pod scale-sleeper-403: decode error status 429: decode json: invalid character 'T' looking for beginning of value
<snip>

Hi, I've seen the project and was wondering if it might be a good idea to add the plugin to the krew package index.

Krew is a kubectl plugin manager and it would be great to see kboom in there.

https://github.com/kubernetes-sigs/krew

If there are any questions I'm happy to help :)