-
|
Hello, When I useing Knative serving. I found that every time knative serving will start at least 2 pods to provide services, I checked the code and found that this is a fixed value in KPA mode ( I would like to ask, what is the reason for this? Is it possible to change this to be configurable? and thank you for the reply, Knative is a great job! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
the code position is here https://github.com/knative/serving/blob/main/pkg/reconciler/autoscaling/kpa/kpa.go#L52 and value would not be changed in any other place. |
Beta Was this translation helpful? Give feedback.
-
|
The activator is multi-tenant so it handles scale to zero for numerous Knative Services. Activators sorta 'scale' out horizontally. Ideally we don't want them all to handle traffic for all revisions so we select a few activators (potentially of many) to act as the 'shield' for revisions. I'm wondering if you're referring to the number of containers that are in the Pod that Knative creates. We have our own sidecar the queue-proxy that's there to enforce the concurrency limits you set. It also tries to manage the shutdown of the Pod gracefully by making sure traffic is drained. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I mean the the number of pod that Knative create in the initial status. every time knative create at least two pod, and I find that the reason is the Much thanks for you reply! |
Beta Was this translation helpful? Give feedback.
-
To clarify Knative doesn't create an activator when a user creates a Knative service. Activators are part of the Knative control plane and operators can configure their how many replicas there are. What is dynamic is the # of activators that are placed in the request path. There is some documentation around configuring that here. https://knative.dev/docs/serving/load-balancing/activator-capacity/ Knative will use at least two activators for high availability |
Beta Was this translation helpful? Give feedback.
The activator is multi-tenant so it handles scale to zero for numerous Knative Services.
Activators sorta 'scale' out horizontally. Ideally we don't want them all to handle traffic for all revisions so we select a few activators (potentially of many) to act as the 'shield' for revisions.
I'm wondering if you're referring to the number of containers that are in the Pod that Knative creates. We have our own sidecar the queue-proxy that's there to enforce the concurrency limits you set. It also tries to manage the shutdown of the Pod gracefully by making sure traffic is drained.