Kubernetes#

Lithops with Kubernetes as serverless compute backend.

Installation#

Install Kubernetes backend dependencies:

python3 -m pip install lithops[kubernetes]

Configuration#

Edit your Lithops config and add the following keys:

  lithops:
      backend : k8s

Make sure you have a kubernetes cluster configuration file.
- Option 1: You have the config file in ~/.kube/config
- Option 2: You have the config file in another location, and you exported the KUBECONFIG variable:
```
export KUBECONFIG=<path-to-kube-config-file>
```
- Option 3: You have the config file in another location, and you set the kubecfg_path var in the Lithops config:
```
k8s:
    kubecfg_path: <path-to-kube-config-file>
```

Configure a private container registry for your runtime#

Configure Docker Hub#

To configure Lithops to access a private repository in your Docker Hub account, you need to extend the kubernetes config and add the following keys:

k8s:
    ....
    docker_server    : docker.io
    docker_user      : <Docker Hub username>
    docker_password  : <Docker Hub access token>

Configure IBM Container Registry#

To configure Lithops to access to a private repository in your IBM Container Registry, you need to extend the kubernetes config and add the following keys:

k8s:
    ....
    docker_server    : us.icr.io
    docker_user      : iamapikey
    docker_password  : <IBM IAM API KEY>
    docker_namespace : <namespace>  # namespace name from https://cloud.ibm.com/registry/namespaces

Summary of configuration keys for Kubernetes:#

Group	Key	Default	Mandatory	Additional info
k8s	kubecfg_path		no	Path to the kubecfg file. Mandatory if the config file is not in `~/.kube/config` or the `KUBECONFIG` env var is not present
k8s	kubecfg_context		no	Kubernetes context to use from your kubeconfig file. The default active context will be used if not provided
k8s	namespace	default	no	Kubernetes namespace to use for Lithops execution
k8s	docker_server	docker.io	no	Container registry URL
k8s	docker_user		no	Container registry user name
k8s	docker_password		no	Container registry password/token. For Docker Hub, log in to your Docker Hub account and generate a new access token here
k8s	rabbitmq_executor	False	no	Alternative K8s backend that accelerates parallel function execution (map) by using RabbitMQ group calls and warm-state pods with higher granularity. For more information, see here.
k8s	max_workers	100	no	Max number of workers per `FunctionExecutor()`
k8s	worker_processes	1	no	Number of Lithops processes within a given worker. This can be used to parallelize function activations within a worker. It is recommended to set this value to the same number of CPUs as the container.
k8s	runtime		no	Docker image name.
k8s	runtime_cpu	1	no	CPU limit. Default 1vCPU
k8s	runtime_memory	512	no	Memory limit in MB. Default 512MB
k8s	runtime_timeout	600	no	Runtime timeout in seconds. Default 600 seconds
k8s	master_timeout	600	no	Master pod timeout in seconds. Default 600 seconds
k8s	container_security_context	PSS Baseline (drop ALL caps, no privilege escalation, RuntimeDefault seccomp)	no	Mapping injected as the container `securityContext` on every Lithops pod. Set to `null` to disable.
k8s	pod_security_context		no	Mapping injected as the pod-level `securityContext`. Required for clusters enforcing Pod Security Standards Restricted (e.g. EGI Rancher, GKE Autopilot, OpenShift). The runtime image must have a non-root `USER` directive — the bundled `runtime/kubernetes/Dockerfile` and the auto-built default ship with `USER 1000:1000`.
k8s	runtime_arch	auto-detected from cluster nodes; falls back to `amd64` if mixed or unknown	no	Architecture passed to `docker build --platform=linux/<arch>`. Set explicitly when targeting a specific architecture on a mixed-arch cluster. Allowed values: `amd64`, `arm64`.

Running on Pod Security Standards Restricted clusters#

Clusters enforcing the Pod Security Standards “Restricted” profile (Rancher with EGI policies, GKE Autopilot, OpenShift, AKS with Azure Policy, EKS with admission controllers) require pods to run as a non-root user with additional hardening. The bundled runtime image and the auto-built default already ship as USER 1000:1000, so a custom non-root rebuild is no longer required — set pod_security_context to opt in:

k8s:
    pod_security_context:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
        seccompProfile:
            type: RuntimeDefault
    container_security_context:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
            drop: ["ALL"]
        seccompProfile:
            type: RuntimeDefault

Providing container_security_context fully replaces the defaults — copy the snippet above and adjust if you want to extend rather than override.

Test Lithops#

Once you have your compute and storage backends configured, you can run a Hello World function with:

lithops hello -b k8s -s aws_s3

Viewing the execution logs#

You can view the function executions logs in your local machine using the lithops client:

lithops logs poll

Kubernetes

Contents