[ADOPTERS]: Posit Software, PBC

[mbaynton]

Contact Details

hostedapps-team@posit.co

Company or Organization

Posit Software, PBC

Product or Project

Posit Connect Cloud

Status

• We have a project or product that is in development
• We have a project or product that is publicly available in prerelease form
• We have a project or product that is in production and publicly available
• We have a project or product that is in production and used internally

Where can we learn more?

https://connect.posit.cloud/

More information

Using Knative Serving, primarily as a solution to scale containers to zero and restart them in response to incoming http requests while utilizing kubernetes and the kubernetes scheduler to place workloads.

Notable features of our integration include:

• The stuff going on inside our pods once knative starts them is pretty nonstandard. Applications are sometimes "built" (downloaded from somewhere, dependencies installed) in the same container that later serves the application. A process coordinates these activities in each container and serves sufficient responses for knative to think the pod is working correctly before the real application is ready. This process also has queue-proxy's code compiled in, and the queue-proxy sidecar is not present.
• Various modifications to pods started from knative services via a mutating webhook. Primarily these are workarounds to add attributes that are present on the core pod spec but cannot be set via the knative service, such as volumes and hostUsers. This is also how we remove the queue-proxy sidecar.

Features we would love include:

• Sticky load balancing. Currently our platform does not support horizontal scaling past 1 pod, primarily because the content frameworks we support are highly stateful and knative doesn't have stateful routing. Horizontal scaling is a future requirement for us and we have some ideas for how to hack this in, but we would want to be involved in any coordinated efforts to add this feature.
• A feature that caused a kservice to scale to zero immediately in response to an API call.
• Ability to scale to another order of magnitude in number of knative services that can be defined on the cluster but scaled to zero. We find that the overall memory requirements on control plane nodes are very high when many thousands of kservices are defined.

There's a few bugs/pain points impacting us as well related to the queue-proxy disconnecting websockets every 5 minutes and kservice deletion performance under kourier, but I should really file proper issues for those.

[dprotaso]

Thanks for the info - I've created a PR to add you to the ADOPTERS.md file

[dprotaso]

For stick sessions we have an open issue - knative/serving#8160

But the reality is it's hard to make it work reliably unless all traffic is going through our activator. Unless there is a portable way (across proxies) for the activator to hint to the upstream ingress a potential backend to route traffic to - so it's sorta always remained on the back burner.

A feature that caused a kservice to scale to zero immediately in response to an API call.

Curious what would you use this for?

Ability to scale to another order of magnitude in number of knative services that can be defined on the cluster but scaled to zero. We find that the overall memory requirements on control plane nodes are very high when many thousands of kservices are defined.

What scale limits are you hitting now and what components are you seeing consume the most memory that's acting as a bottle neck?