-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Initial sandbox API CRI integration (implement Controller.Start) #7228
Conversation
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
9dc253a
to
d1e6777
Compare
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
/test pull-containerd-sandboxed-node-e2e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
} | ||
|
||
func (c *Controller) Start(ctx context.Context, id string) (_ *api.ControllerStartResponse, retErr error) { | ||
sandboxInfo, err := c.client.SandboxStore().Get(ctx, id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering that we should handle network here or not. 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong opinion on this. Since we can build on all platforms and turn it off, it's ok to keep it in CRI for now. We can brainstorm more on this.
@fuweid thanks for looking into this. I've added a few TODOs to follow up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It is milestone.
Let's move it forward!
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a small nit .. progress! let's move forward
Sandbox API has Controller interface used to manage a sandbox instances lifecycle (kin of
TaskService
interface to manage tasks lifecycle). containerd shims that support sandbox API supposed to implement this interface at shim level. This way we can expose different sandbox implementations in containerd (like podsandbox aka pause container or microVM).In case of CRI/Kube, primary user of the
Controller
interface is going to be our CRI plugin (which we forked in #7164 for sandbox work). Depending on CRI request, it'll call appropriate controller func (e.g.RunPodSandbox
invokesController.Start
,StopPodSandbox
invokesController.Stop
, etc).So the end-goal is to have CRI rely on
Controller
interface instead of managing pod-sandbox directly. This PR starts refactoring and handlesController.Start
implementation. All relevant CRI code is now moved topodsandbox
package and implements Start func to setup container spec and launch a task.For pod-sandbox, we'll have an in-memory implementation. Once migrated,
Controller
interface will getttrpcRemoteController
, which will call-in shims instead.