Spartakus aims to collect information about Kubernetes clusters. This information will help the Kubernetes development team to understand what people are doing with it and to make it a better product.

This chart bootstraps a Spartakus deployment on a Kubernetes cluster using the Helm package manager.


Kubernetes 1.3+ with Beta APIs enabled

Note: Spartakus does not report any personally identifiable information (PII). Anything that might be identifying, including IP addresses, container images, and object names are anonymized. We take this very seriously. If you think something we are collecting might be considered PII, please do let us know by raising an issue here.

Running Spartakus is a voluntary effort, that is, it is not baked into Kubernetes in any way, shape, or form. In other words: it operates on an opt-in basis—if you don’t want to run it, you don’t have to. If you want to run your own server and collect data yourself, you can do that, too—see also the user docs for more info on how to customize the reports.

What is in a report?

Reports include a user-provided cluster identifier, the version strings of your Kubernetes master, and some information about each node in the cluster, including the operating system version, kubelet version, container runtime version, as well as CPU and memory capacity.

How do I run it?

To start using Spartakus in your cluster, use the following:

$ kubectl run spartakus \
– \
— volunteer –cluster-id=$(uuidgen)

This will generate a deployment called spartakus in your default namespace which sends a report once every 24 hours. It will report a random UUID as the cluster ID. Note that if you stop this deployment and re-run it, the UUID will be different. Managing the UUIDs is outside of the scope of Spartakus.

If you want to save the YAML manifest that the command above produces, you can simply execute the following (note: the –export flag strips cluster-specific information):

$ kubectl get deployment spartakus –export -o yaml
You needn’t worry about CPU and memory usage of Spartakus, its resource usage footprint is minimal. If you’re still concerned, you can edit the deployment to request a small share of CPU and memory; for example, Spartakus will work fine with 1m CPU and 10Mi mem on a five-node cluster.

What will we do with this information?

The information reported by Spartakus, in aggregate, will help the Kubernetes development teams prioritize our efforts. The better we understand what people are doing, the better we can focus on the important issues.


Note that you only will need this section if you’re contributing to Spartakus.

To build artifacts, we’re using make. Simply run make or make the test to build the binary in bin/; the container image build is carried out through Docker and hence requires you’ve got Docker running on your machine.


Anything we add will follow the same strict privacy rules as outlined above. Some examples of things we would consider adding:

  • How many namespaces exist.
  • A histogram of how many pods, services, deployments, etc. exist on a per-namespace basis.
  • The average lifetime of namespaces, pods, services, etc.

Tell us about a new Kubernetes application


Never miss a thing! Sign up for our newsletter to stay updated.


Discover and learn about everything Kubernetes