Skip to content

Building Container Images⚓︎

Building custom container images might be required for a lot of features within prokube, e.g. for creating advanced Kubeflow pipelines, KServe predictors and transformers, or agent runtimes.

Notebook images ship with docker and docker buildx pre-configured to use a shared BuildKit daemon running in the cluster. No setup or separate shell is needed — docker buildx build works out of the box from any terminal in your notebook (JupyterLab, VS Code, or RStudio).

Note: There is no local Docker daemon, so plain docker build will not work. Use docker buildx build --push instead (see examples below).

Building and Pushing Images⚓︎

Images are built remotely and pushed directly to a registry. The --push flag is required:

# Build and push
docker buildx build -t <registry>/<image>:<tag> --push .

# Build a multi-platform image
docker buildx build --platform linux/amd64,linux/arm64 \
    -t <registry>/<image>:<tag> --push .

Login to a registry first if required: 

docker login -u <username> registry-1.docker.io

Registry credentials are not shared. Login credentials are stored only in your notebook pod's memory and are never accessible to other users. Builds run in the shared BuildKit daemon, but each build's push goes directly to your registry — built image layers inside the daemon are not accessible to others.

Images live in the registry, not locally. Because builds run in a remote rootless daemon, there is no local image store. The built image is only accessible after it has been pushed to a registry (--push). It can then be pulled by Kubernetes workloads (pipeline components, KServe predictors, etc.) or by your local machine. Running containers interactively from within the notebook is not possible — the notebook pod does not have access to a container runtime.

Technical Details⚓︎

  • The remote builder is configured automatically at notebook startup via an s6 init script — no manual setup needed
  • Builds run in a shared rootless BuildKit daemon deployed in the cluster (buildkit namespace); your notebook pods do not need any elevated privileges
  • Build layer cache is persisted in the daemon's volume across sessions, so repeated builds of similar images are fast
  • The BUILDKIT_HOST environment variable controls which daemon is used; it is pre-configured in the notebook image and can be overridden via a PodDefault