Knative: Operator’s Handbook

Reproducible image deployments

As you've learned in Revisions page, Knative uses the Revisions objects to snapshot your deployment configuration (container image, and other settings). This allows you to roll back to a previously known good version.

But what if you deployed your app from image myimage/myapp:latest and someone pushes a new image to the existing :latest tag? 1

Therefore, Knative resolves a “tag reference” to an immutable image reference. For example, when you deploy a Service with image like:

gcr.io/google-samples/hello-app:1.0

Knative will resolve the “tag” reference to an “immutable” reference, so the resulting Revision object will have a imageDigest field that's used to create the Pods.

gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

This way, Knative does not rely on “image tags” anymore and provides reproducible deployments.

Under the covers

Knative Serving’s controller component is performs this resolution by querying the image from the Docker Registry v2 API.

Tag resolution uses the Kubernetes service account of the workload (Pod) you're deploying2 to authenticate to the registry (not the credentials of controller Pod).

Make sure the Namespace you're “deploying to” has the image pull secrets configured properly.


  1. Normally in Kubernetes, this would cause newly created Pods to run with a different image than the other pods, which is not desirable for reproducibility. ↩︎

  2. By default, Kubernetes has a default ServiceAccount in each namespace, make sure it has an imagePullSecret associated to it for private registries. ↩︎