Multiple containers in the same pod

[VladimirSmogitel]

In what area(s)?

/area API
/area autoscale
/area build
/area monitoring
/area networking
/area test-and-release

Ask your question here:

Is it possible to deploy a multi-container pod by executing one Knative service creation yaml? All exampled that I have seem create one container(app) per pod. We would like to deploy 2 or 3 containers into the same pod but only one of the containers will listen on port 8080. Is it possible? If so what is the structure of this yaml? Is ti possible for a containers to listen on a port other than 8080 to received data or does it have to be 8080? Thank you.

[mattmoor]

It is not possible to use multiple containers. Can you elaborate on the use case?

It is possible to specify a port via containerPort: in the single container's spec.

[PascalStieber]

The Use-Case could be, that I want to have a database (mongodb) and my backend service (Spring) in the same pod. I only want to have to write a single service definition.

[mattmoor]

@PascalStieber I'd like to better understand how you expect to use Mongo in this case. Mongo seems like a canonical example of "state" and we're really oriented towards "stateless" services. If you want any sort of durability out of the data stored into Mongo, then you are gonna have a bad time.

Imagine that each pod lives for ~1 request, what is the colocated Mongo doing for you?

[mattmoor]

While we've adopted the PodSpec shape in v1beta1, we don't plan to relax this in the v1 timeframe.

Sidecars can be injected around the Knative abstraction, like Istio does for the mesh, but we don't plan to let users bring their own.

[duglin]

@mattmoor could you elaborate a little on why this restriction is needed when, as you said, there are mechanisms that allow people to get the same net result, but not nearly as UX friendly.

[tchupp]

I have a use case where this would be quite useful.
Currently I am running a gRPC app with a sidecar container: (https://github.com/cloudendpoints/esp)
The sidecar handles authentication, rate limiting, etc
My current set up in K8s has these two containers running together in a single pod, with only the sidecar exposed. This keeps my gRPC app secure. Both containers are stateless, and could scale freely.
This seems like the perfect use-case for KNative! And I really want to try it out, except I can’t bring my own sidecar.

[kwyn]

Another use case (as ill-advised as it may be) is for a screen shot service that has a container running headless chrome that another container abstracts a grpc endpoint for to create screen shots. So effectively there are two containers running. One running a chrome process (not exposed to the world) and another running a go process (exposed to the world).

I would also in the future want to run the esp side card same as @tchupp