Does the image build processes spawn by buildkit pods running on kubernetes use its cgroup?

Open
#6,432 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
30/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
dockerfile, kubernetes, linux

Research direction

No source file or test is named. Start by examining the buildkitd configuration using the rootless OCI worker with --oci-worker-no-process-sandbox on cgroup v2, then reproduce the Dockerfile pip-install step in Kubernetes and trace the exit code 137. Done means identifying whether the process uses the expected cgroup and documenting or correcting the cause of the timeout and kill.

Written by the indexing model from the issue text.

Description

area/kubernetes status/triage
Description

I notice my buildkit memory usage is well below the requested memory configurations on my kubernetes cluster, but the buildctl docker builds calls timed out.

After checking the traceID, i notice at a certain step of the dockerfile runing pip installs... it got killed with exit code 137, pod memory still has a lot to spare

Wanted to know if anyone has any idea how this could have happened?

A little more context
My k8s nodes are using cgroup v2
I'm running buildkitd with - --oci-worker-no-process-sandbox
Image tag: v0.24.0-rootless

Dominant language
Go
Stars
10.3k
Forks
1.5k
Avg merge
1d 23h
Merged PRs (30d)
48

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from moby/buildkit

All issues in moby/buildkit

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.