This document provides a high-level description of the resources deployed to a Kubernetes cluster in order to run Knative Serving. The exact list of resources is going to change frequently during the current phase of active development. In order to keep this document from becoming out-of-date frequently it doesn't describe the exact individual resources but instead the higher level objects which they form.
Knative Serving depends on an KIngress implementation in order to function. KIngress is pluggable, and implementations exist for a variety of ingress providers, including Istio, Contour and Kourier.
There are four primary components to the Knative Serving system. The first is the Controller which is responsible for updating the state of the cluster based on user input. The second is the Webhook component which handles validation of the objects and actions performed. The third is an Activator component which brings back scaled-to-zero pods and forwards requests. The fourth is the Autoscaler which scales pods as requests come in.
The controller processes a series of state changes in order to move the system from its current, actual state to the state desired by the user.
All of the Knative Serving components are deployed into the knative-serving
namespace. You can see the various objects in this namespace by running
kubectl -n knative-serving get all
(minus some admin-level resources like service accounts).
To see only objects of a specific type, for example to see the webhook and
controller deployments inside Knative Serving, you can run
kubectl -n knative-serving get deployments
.
The Knative Serving controller creates Kubernetes resources when Knative Serving
resources are created and updated. These sub-resources will be created in the
same namespace as their parent Knative Serving resource, not the
knative-serving
namespace. For example, if you create a Knative Service in
namespace 'foo' the corresponding Deployment and ReplicaSet resources will also
be in namespace 'foo'.
All of these components are run as a non-root user and disallow privilege escalation.
The various Kubernetes resource configurations are organized as follows:
# Knative Serving core resources
config/core/...
# Third-party resources, such as the net-istio ingress provider yaml.
third_party/...
To view all of the custom resource definitions created, run
kubectl get customresourcedefinitions
. These resources are named according to
their group, i.e. custom resources created by Knative Serving end with
serving.knative.dev
or internal.knative.dev
.
View the Knative Serving specific deployments by running
kubectl -n knative-serving get deployments
. These deployments will ensure that
the correct number of pods are running for that specific deployment.
For example, given:
$ kubectl -n knative-serving get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
activator 1 1 1 1 5d
autoscaler 1 1 1 1 5d
controller 1 1 1 1 5d
webhook 1 1 1 1 5d
Based on the desired state shown above, we expect there to be a single pod running for each of the deployments shown above. We can verify this by running and seeing similar output as shown below:
$ kubectl -n knative-serving get pods
NAME READY STATUS RESTARTS AGE
activator-c8495dc9-z7xpz 2/2 Running 0 5d
autoscaler-66897845df-t5cwg 2/2 Running 0 5d
controller-699fb46bb5-xhlkg 1/1 Running 0 5d
webhook-76b87b8459-tzj6r 1/1 Running 0 5d
Similarly, you can run the same commands in the istio (istio-system
)
namespaces to view the running deployments. To view all namespaces, run
kubectl get namespaces
.
To view the service accounts configured for Knative Serving, run
kubectl -n knative-serving get serviceaccounts
.
To view all cluster role bindings, run kubectl get clusterrolebindings
.
Unfortunately there is currently no mechanism to fetch the cluster role bindings
that are tied to a service account.