1:23 a.m.
On 2020/6/3 02:50, Matt Heon wrote:
On 2020-06-02 18:30, Eric Ernst via Podman wrote:
> Hey pod-folk –
>
> In the Kata Containers community, for 2.0 Kata we are looking to
> *just* support integration through a gRPC server/client interface,
> utilizing the ‘v2-shim’ API. This is how we integrate with
> CRIO/containerd, and we are now looking at do similar for both moby
> and Podman.
Hello,
Please allow me to add a few background for the change. Before the
v2-shim API, we have runc like command line (kata-runtime) that would
end up with one kata-shim process per IO stream for a pod. The life
cycle of the kata-shim process is identical to the IO stream. That means
we at least have to keep running one kata-shim per container in a pod
and possibly more with one kata-shim per container exec. And it leads to
kata-shim process explosion and causes a lot of management troubles for
sysadmins and SREs in production.
Luckily enough, we migrated from the above architecture to a much
simpler v2-shim architecture, where there is only one shimv2 process per
pod. The transition is also illustrated in picture [1].
For podman, while it is working with the kata-runtime command line, we
would like to encourage you to also migrate to the v2-shim API to make
it easier for users to adopt podman + Kata, and help them avoid the
kata-shim process explosion problem. It is really important from
production users point of view.
Cheers,
Tao
[1].
https://raw.githubusercontent.com/kata-containers/documentation/master/de...
>
> I wanted to get feedback from Podman community on whether integrating
> through v2shim server/client between podman/kata is:
>
> 1. Technically feasible
Our general contract for an OCI runtime is that it must fulfill the
inteface at [1]. The biggest things there that Kata may not implement:
- We need to be able to run a specific Podman command (provided by
Podman when the container is started) when a container exits.
- We need the OCI runtime to write a file containing the container's
exit code when the container exits (as ASCII, not binary).
(These two also apply to exec sessions, but that is less critical IMO)
These don't necessarily have to be done by Kata itself - if they can
be worked into a wrapper service, that's perfectly fine by us, but we
do need both of them to ensure core Podman functionality.
Other things (attach stream format, if it's different) can be coded
around in the actual implementation of an OCI runtime that talks to
Kata via this gRPC interface.
My other concern would be that there's no expectation of asyncronous
communication from Kata - without a daemon, we don't have anything
that can listen for messages from Kata.
> 2. A design pattern ya’ll are amenable to.
>
So long as the implementation fits into our OCI runtime interface (and
we'd be happy to consider modifications to that interface, if they're
needed), I think this sounds fine. If this ends up dragging in any
large dependencies that increase binary size significantly, I'd want
to gate it behind a build tag, but otherwise I don't see any problems.
Thanks,
Matt Heon
> Thanks,
> Eric
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any
> attachments, is for the sole use of the intended recipient(s) and
> contains information that is confidential and proprietary to Ampere
> Computing or its subsidiaries. It is to be used solely for the purpose
> of furthering the parties' business relationship. Any review, copying,
> or distribution of this email (or any attachments thereto) is strictly
> prohibited. If you are not the intended recipient, please contact the
> sender immediately and permanently delete the original and any copies
> of this email and any attachments thereto.
[1] https://github.com/containers/libpod/blob/master/libpod/oci.go
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
--
Into something rich and strange.