The kubelet crate supports configuration via the command line, configuration file or environment variables.

NOTE: Custom kubelets built using the kubelet crate can choose which of these methods to support, or may choose to bypass kubelet's built-in configuration system in favour of their own. krustlet-wasi uses standard configuration and supports all configuration methods.

NOTE: Certain flags must be handled at the provider or custom kubelet level. If you are building a custom kubelet using the kubelet crate, please see the “Notes to kubelet implementers” section below.

Configuration values

Command line Environment variable Configuration file Description
-a, –addr KRUSTLET_ADDRESS listenerAddress The address on which the kubelet should listen
–data-dir KRUSTLET_DATA_DIR dataDir The path under which the kubelet should store data (e.g. logs, container images, etc.). The default is $HOME/.krustlet
–hostname KRUSTLET_HOSTNAME hostname The name of the host where the kubelet runs. Defaults to the hostname of the machine where the kubelet is running; pass this if the name in the TLS certificate does not match the actual machine name
–max-pods MAX_PODS maxPods The maximum number of pods to schedule on the kubelet at any one time. The default is 110
-n, –node-ip KRUSTLET_NODE_IP nodeIP The IP address of the node registered with the Kubernetes master. Defaults to the IP address of the kubelet hostname, as obtained from DNS
–node-labels NODE_LABELS nodeLabels The labels to apply to the node when it registers in the cluster. See below for format
–node-name KRUSTLET_NODE_NAME nodeName The name by which to refer to the kubelet node in Kubernetes. Defaults to the hostname
-p, –port KRUSTLET_PORT listenerPort The port on which the kubelet should listen. The default is 3000
–cert-file KRUSTLET_CERT_FILE tlsCertificateFile The path to the TLS certificate for the kubelet. The default is (data directory)/config/krustlet.crt
–private-key-file KRUSTLET_PRIVATE_KEY_FILE tlsPrivateKeyFile The path to the private key for the TLS certificate. The default is (data directory)/config/krustlet.key
–insecure-registries KRUSTLET_INSECURE_REGISTRIES insecureRegistries A list of registries that should be accessed using HTTP instead of HTTPS. On the command line or environment variable, use commas to separate multiple registries
–x-allow-local-modules KRUSTLET_ALLOW_LOCAL_MODULES allowLocalModules If true, the kubelet should recognise references prefixed with ‘fs’ as indicating a filesystem path rather than a registry location. This is an experimental flag for use in development scenarios where you don’t want to repeatedly push your local builds to a registry; it is likely to be removed in a future version when we have a more comprehensive toolchain for local development.

Node labels format

If you specify node labels on the command line or in an environment variable, the format is a comma-separated list of name=value pairs. For example:

--node-labels mylabel=foo,myotherlabel=bar

If you specify node labels in the configuration file, the format is key-value pairs. For example:

    "node_labels": {
        "mylabel": "foo",
        "myotherlabel": "bar"

Configuration file location

By default, the configuration file is located at $HOME/.krustlet/config/config.json. The kubelet crate does not define a common way to override this. However, custom kubelets built on kubelet may provide such a mechanism.

The krustlet-wasi kubelet does not currently provide a way to override the default location.

TODO: should we build in a standard way of overriding the file location?


If you specify the same setting in multiple places - for example, both in the configuration file and on the command line - then the precedence is:

  • Command line flags take precedence over environment variables
  • Environment variables take precedence over the configuration file

This allows you to conveniently override individual settings from a configuration file, for example by writing MAX_PODS=200 krustlet-wasi or krustlet-wasi --max-pods 200.

If you specify node labels in multiple places, the collections are not combined: the place with the highest precedence takes effect and all others are ignored.

Notes to kubelet implementers

Some flags require you to support them in your provider or main code - they are not implemented automatically by the kubelet core. These flags are as follows:

  • --bootstrap-file - should be passed to kubelet::bootstrap if you use the bootstrapping feature
  • --data-dir - this should be used to construct the FileStore if you use one
  • --x-allow-local-modules - if specified you should compose a FileSystemStore onto your normal store

See the file for examples of how to honour these flags.

If you can’t honour a flag value in your particular scenario, then you should still check for it and return an error, rather than silently ignoring it.