Does KNative serving not allow initContainers field?

Question

I'm trying to deploy a service with a container and a initContainer, using KNative.
I installed Istio without sidecar injection if that matters.
This is the error I get:

Internal error occurred: admission webhook "webhook.serving.knative.dev" denied the request: validation failed: must not set the field(s): spec.template.spec.initContainers
volumes not mounted: [some_script]: spec.template.spec.containers[0].volumeMounts

My YAML file:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - image: image
        imagePullPolicy: IfNotPresent
        name: my-container
        ports:
        - containerPort: 1234
        volumeMounts:
        - mountPath: ........
          name: .....
          .......
      initContainers:
      - args:
        - -c
        - /some_dir/some_script.sh
        command:
        - /bin/sh
        image: alpine
        imagePullPolicy: IfNotPresent
        name: my-init-container
        volumeMounts:
        - mountPath: /some_dir
          name: some_dir
        - mountPath: /some_dir/some_script.sh
          name: some_script
          subPath: some_script.sh
      - configMap:
          defaultMode: 511
          name: some_script.sh
        name: some_script

Thanks!

Answer 1

Init containers are not there in the Knative serving API spec which leaves me to believe that it's not supported.

Answer 2

To add a little more color to Arghya's answer, Knative deliberately excludes init containers right now because they can induce large (unbounded) amounts of additional latency during cold-start. Additionally, one of the goals for Knative was to simplify much of the Kubernetes API, so solutions like init containers which can also be implemented as startup parts of the user container were blocked off.

One reason for being restrictive here is that it's much easier to add to an API later than to remove from it, so the initial API was minimal to see which constraints were substantially onerous.