Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support V3 containerd task service and Sandboxers #385

Open
cpuguy83 opened this issue Nov 3, 2023 · 9 comments
Open

Support V3 containerd task service and Sandboxers #385

cpuguy83 opened this issue Nov 3, 2023 · 9 comments
Labels
enhancement New feature or request

Comments

@cpuguy83
Copy link
Member

cpuguy83 commented Nov 3, 2023

In containerd 1.7 the v3 task service was introduced.
In v3 both ttrpc and grpc are supported, choosing what RPC to use should definitely take into account memory overhead.

There's no real rush here, but V3 does buy us some simplified logic in bootstrapping the shim and support for "sandboxer" services.

"Sandboxer" can do a number of things, the immediate benefit is we don't have to have this logic that guesses that the first container sent to the shim (with a cri label) is actually the "pause" container.
Instead it leaves that implementation detail up to the sandboxer.
It would also make the "shared" mode as described in our readme a first class citizen.

Related:

@jprendes
Copy link
Collaborator

jprendes commented Nov 6, 2023

Sorry if these are silly questions:

  • Would we gain support for v3 through the containerd-shim crate?
  • Is v3 being backported to older containerd?
  • If not, do we want to keep the v2 code for compatibility with older containerd?
  • Could we remove the special handling for pause container since we support native/linux contianers (what we use for sidecar containers)

@cpuguy83
Copy link
Member Author

cpuguy83 commented Nov 7, 2023

Would we gain support for v3 through the containerd-shim crate?

I think that's where we'd need to focus

Is v3 being backported to older containerd?

No

If not, do we want to keep the v2 code for compatibility with older containerd?

Yep

Could we remove the special handling for pause container since we support native/linux contianers (what we use for sidecar containers)

We probably should for compatability sake... but this is going to start getting hairy, I think, with sandboxers.
In this case the sandboxer would be responsible for managing the (pod) sandbox.

@jsturtevant
Copy link
Contributor

I believe rust-extensions added the sandbox apis a couple releases ago: containerd/rust-extensions#145

@Mossaka Mossaka added the enhancement New feature or request label Jan 2, 2024
@Burning1020
Copy link
Member

Hi, I'm the maintainer of Kuasar, we have forked rust-extesions and made a "sandbox crate" that implements Controller service of containerd/api/services/sandbox/v1/sandbox.proto and provides a scaffold for "sandboxer". I believe this crate can help in your case.

The current origin Sandbox APIs is immature and incomplete, so we are planning to promote our forked containerd. To achive this, we have presented many times on containerd community meeting introduing "sandboxer"(please refer to meeting record) and got approval from many containerd maintainers. There is a tracking issue with v2.0 milestone: containerd/containerd#9431

After this issue, we also expect to push the "sandbox crate" to the origin repo. I think we can contribute together if runwasi plans to support Sandbox API too.

@squillace
Copy link

That would be coolio, @Burning1020 !

@Mossaka
Copy link
Member

Mossaka commented Apr 8, 2024

If I understand this correctly, the issue containerd/containerd#9431 is to track progress for the "sandboxer" APIs, which are different from the sandbox APIs that included in containerd 2.0. Are the sandboxer APIs expected to be included in 2.0 release as well or seperate? Would appreciate some clarifications 🙏 @Burning1020

@Burning1020
Copy link
Member

If I understand this correctly, the issue containerd/containerd#9431 is to track progress for the "sandboxer" APIs, which are different from the sandbox APIs that included in containerd 2.0.

The API is part of it, exactly #9736 and #9903, the others are some code refactoring.

Are the sandboxer APIs expected to be included in 2.0 release as well or seperate?

We all(including containerd maintainers) expect to have sandbox feature released in 2.0 as disscussed in last community meeting, the maintainers are trying best to review while it's heavy workloads. Wolud you guys like to help in review?

@Mossaka
Copy link
Member

Mossaka commented Apr 8, 2024

Wolud you guys like to help in review?

I would love to! I think @cpuguy83 is already actively involved in this part, correct me if I am wrong?

Just to clarify, the sandboxer APIs and sandbox APIs are part of the same feature in containerd 2.0, right?

@Burning1020
Copy link
Member

@Mossaka Thank you. They are in the same feature, the sandboxer APIs should also be involved in 2.0 without which the sandbox feature is hard to use.

Mossaka added a commit to Mossaka/runwasi that referenced this issue Sep 16, 2024
The 'shared' mode in runwasi is not actively maintained and tested. This commit is removing it.

The 'shared' mode will soon be replaced with the Sandboxer API described in containerd#385

Signed-off-by: jiaxiao zhou <jiazho@microsoft.com>
Mossaka added a commit to Mossaka/runwasi that referenced this issue Sep 16, 2024
The 'shared' mode in runwasi is not actively maintained and tested. This commit is removing it.

The 'shared' mode will soon be replaced with the Sandboxer API described in containerd#385

Signed-off-by: jiaxiao zhou <jiazho@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

6 participants