Remove the stub container

[plamenmpetrov]

The queue-proxy container interacts directly with the user workload Firecracker-Containerd container. However, we create a stub lightweight user container still so that CRI Operations such as ContainerStatus, ListContainers do not require additional support. Once firecracker-containerd supports there call, we can decommission the stub.

[ustiugov]

Currently, container and gVisor based sandboxes support function deployment in the same canonical format:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: fibonacci-python
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: docker.io/NAME/NAME:TAG
          ports:
            - name: h2c
              containerPort: 50000

However, due to the workaround we have in Knative fork used by vHive, the format of function deployed in Firecracker needs to be different:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: fibonacci-python
  namespace: default
spec:
  template:
    spec:
      containers:        
        - image: crccheck/hello-world:latest # Stub image. See https://github.com/ease-lab/vhive/issues/68
          ports:
            - name: h2c # For GRPC support
              containerPort: 50051
          env:
            - name: GUEST_PORT # Port on which the firecracker-containerd container is accepting requests
              value: "50051"
            - name: GUEST_IMAGE # Container image to use for firecracker-containerd container
              value: "docker.io/NAME/NAME:TAG"

Please note that vSwarm benchmark YAMLs are written in the canonical format and need to be modified to be used with Firecracker (Issue)

[aryanjain285]

I'm looking into the use of the stub image (crccheck/hello-world:latest) for deploying functions in Firecracker microVMs, as mentioned in the YAML configuration. I understand that this stub image is a workaround, but I was wondering if there's any ongoing or planned effort to eliminate the need for the stub and directly use the actual function image (as specified in the GUEST_IMAGE environment variable)?

More specifically, would it be possible to modify the deployment process so that the container image is passed directly to Firecracker-containerd without relying on the stub? If so, I’d love to contribute toward this change or understand any constraints that prevent this approach.

Looking forward to your thoughts!

Thanks, Aryan.

[leokondrashov]

First, the firecracker-containerd receives the image you need directly. In the process, kubernetes asks another stub container (managed by contained) to respond instead of the intended user container.

The problem is that firecracker-containerd doesn't (or at least didn't) support some of the CRI API calls. If we can make it respond to them correctly, we can remove the stub container. As a first step, we will need to bump the firecracker-containerd version used in vHive. That would be a great contribution to the project.