This page describes how to deploy new services and new revisions to Knative serving.
Before you begin
To use the Google Cloud CLI, you must first setup and configured the command-line tools.
Connecting to GKE clusters
Before you can deploy services to Knative serving, you need to log in to connect to your GKE cluster.
For more information about connecting to your GKE clusters, including additional options, see:
Permissions required to deploy
You need permissions to create, update, and delete on the
apiGroup serving.knative.dev
and kind Service
, and in addition you must have
ONE of the following Identity and Access Management roles:
Images you can deploy
There is no size limit that applies to the container image you can deploy.
You can use containers from any container registry, such as Docker Hub. For information on deploying private images from registries different from Container Registry or Artifact Registry, see Deploying private container images from other container registries.
Deploying a new service
You can specify a container image with a tag
(for example, gcr.io/my-project/my-image:latest
) or with an exact digest
(for example, gcr.io/my-project/my-image@sha256:41f34ab970ee...
).
Deploying to a service for the first time creates its first revision. Note that revisions are immutable. If you deploy from a container image tag, it will be resolved to a digest and the revision will always serve this particular digest.
You can deploy a container using the Google Cloud console, the Google Cloud CLI or from a YAML configuration file.
Click the tab for instructions using the tool of your choice.
Default gcloud
location configuration
If you previously configured a location in the
default
configuration
of Google Cloud CLI, your gcloud
commands use those values by default, including:
compute/region
compute/zone
run/cluster
run/cluster_location
run/platform
run/region
Run the following
gcloud
config command
to view your settings for the default
configuration:
gcloud config configurations describe default
Console
To deploy a container image:
Go to Knative serving in the Google Cloud console:
Click Create service to display the Create service page.
In the form:
From the dropdown menu, select one of the available GKE clusters for your service.
Enter the desired service name. Service names must be unique per region and project or per cluster. A service name cannot be changed later.
Under Connectivity:
- Select Internal if you want to restrict access only to other Knative serving services or services in your cluster that use Istio.
- Select External to allow external access to your service
Note that you can change the connectivity option at any time, as described in Changing service connectivity settings.
Click Next to continue to the second page of the service creation form.
In the form:
In the Container image URL textbox, supply the URL of an image from a supported registry, for example:
us-docker.pkg.dev/cloudrun/container/hello:latest
Optionally, click Show Advanced Settings and the subsequent tabs to set:
Click Create to deploy the image to Knative serving and wait for the deployment to finish.
You have just deployed a service to a Knative serving enabled cluster.
Command line
To deploy a container image:
Run the
gcloud run deploy
command:gcloud run deploy SERVICE --image IMAGE_URL
Replace SERVICE with the name of the service to which you want to deploy. If the specified service does not exist, a new service is created.
Replace IMAGE_URL with a reference to the container image, for example,
gcr.io/cloudrun/hello
.Additional deployment options:
To deploy to a namespace other than the default, you must specify that namespace using the
--namespace
parameter.To deploy to a location other than the default configuration, you must specify the
name
andlocation
of the cluster with the--cluster
and--cluster-location
parameters:gcloud run deploy SERVICE --cluster CLUSTER-NAME --cluster-location CLUSTER-LOCATION
You can set connectivity options with the
--connectivity
flag as described in Changing service connectivity settings to specify internal or external access.For Knative serving on VMware, you must include the
--kubeconfig
parameter and specify your configuration file:gcloud run deploy SERVICE --image IMAGE_URL --kubeconfig KUBECONFIG-FILE
Wait for the deployment to finish. Upon successful completion, a success message is displayed along with the URL of the deployed service.
YAML
You can store your service specification in a YAML
file and then
deploy it using the Google Cloud CLI.
Create a new
service.yaml
file with this content:apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: spec: containers: - image: IMAGE
Replace
- SERVICE with the name of your Knative serving service
- IMAGE with the URL of your container image.
You can also specify more configuration such as environment variables or memory limits.
Deploy the new service using the following command:
gcloud run services replace service.yaml
Deploying a new revision of an existing service
You can deploy a new revision using the Google Cloud console, the gcloud
command line, or a YAML configuration file.
Note that changing any configuration settings results in the creation of a new revision, even if there is no change to the container image. Each revision created is immutable.
Click the tab for instructions using the tool of your choice.
Console
To deploy a new revision of an existing service:
Go to Knative serving in the Google Cloud console:
Locate the service you want to update in the services list, and click on it to open the details of that service.
Click EDIT & DEPLOY NEW REVISION. This displays the revision deployment form:
If needed, supply the URL to the new container image you want to deploy.
Optionally, set:
To send all traffic to the new revision, check the checkbox labelled Serve this revision immediately. To gradually roll out a new revision, uncheck that checkbox: this will result in a deployment where no traffic is sent to the new revision--follow the instructions for gradual rollouts after you deploy.
Click DEPLOY and wait for the deployment to finish.
Command line
To deploy a container image:
Run the
gcloud run services update
command:gcloud run services update SERVICE --image IMAGE_URL
- A revision suffix is automatically assigned for each revision. If you want to specify your own revision suffix, add the --revision-suffix parameter.
Replace SERVICE with the name of the service to which you want to deploy. If the specified service does not exist, a new service is created.
Replace IMAGE_URL with a reference to the container image, for example,
gcr.io/cloudrun/hello
.Additional deployment options:
To deploy to a namespace other than the default, you must specify that namespace using the
--namespace
parameter.To deploy to a location other than the default configuration, you must specify the
name
andlocation
of the cluster with the--cluster
and--cluster-location
parameters:gcloud run deploy SERVICE --cluster CLUSTER-NAME --cluster-location CLUSTER-LOCATION
You can set connectivity options with the
--connectivity
flag as described in Changing service connectivity settings to specify internal or external access.For Knative serving on VMware, you must include the
--kubeconfig
parameter and specify your configuration file:gcloud run deploy SERVICE --image IMAGE_URL --kubeconfig KUBECONFIG-FILE
Wait for the deployment to finish. Upon successful completion, a success message is displayed along with the URL of the deployed service.
YAML
You can download the configuration of an existing service into a
YAML file with the gcloud run services describe
command by using the
--format=export
flag.
You can then modify that YAML file and deploy
those changes with the gcloud run services replace
command.
You must ensure that you modify only the specified attributes.
Download the configuration of your service into a file named
service.yaml
on local workspace:gcloud run services describe SERVICE --format export > service.yaml
Replace SERVICE with the name of your Knative serving service.
In your local file, update the revision settings in any child attribute of the
spec.template
.Deploy the new revision:
gcloud run services replace service.yaml
Deploying images from other Google Cloud projects
You can deploy container images from other Google Cloud projects if you set the correct IAM permissions:
In the Google Cloud console console, open the project for your Knative serving service.
Obtain your service account info:
For clusters on Google Cloud, copy the email of the Compute Engine default service account. It has the suffix @developer.gserviceaccount.com
For other clusters, create a Google Cloud service account and download the credentials. Add these credentials as the default
imagePullSecrets
of the Kubernetes Service Account.
Open the project that owns the container registry you want to use.
Click Add to add a new principal.
In the New principals text box, paste in the email of the service account that you copied earlier.
In the Select a role dropdown list, select the role to read from the registry:
- Artifact Registry, including gcr.io repositories in Artifact Registry: Artifact Registry -> Artifact Registry Reader
- Container Registry: Storage -> Storage Object Viewer
Deploy the container image to the project that contains your Knative serving service.
For stronger security, you can limit grant access:
- Artifact Registry: Grant the role on the repository that stores your container images.
- Container Registry: Grant the role on the Cloud Storage bucket that stores your container images.
Deploying private container images from other container registries
This section describes setting up correct permissions to deploy container images from an arbitrary private registry to Knative serving. A private container registry requires credentials to access the container image. Note that you do not need to follow these steps to deploy private container images from Container Registry (Deprecated) or Artifact Registry in the same project as your cluster.
To be able to deploy a private container image, you must create an
imagePullSecret
type Kubernetes secret and associate it with a service account:
Create an
imagePullSecret
secret calledcontainer-registry
:kubectl create secret docker-registry container-registry \ --docker-server=DOCKER_REGISTRY_SERVER \ --docker-email=REGISTRY_EMAIL \ --docker-username=REGISTRY_USER \ --docker-password=REGISTRY_PASSWORD
- Replace DOCKER_REGISTRY_SERVER with your private registry FQDN (ex: https://gcr.io/ for Container Registry or https://hub.docker.com for DockerHub).
- Replace REGISTRY_EMAIL with your email.
Replace REGISTRY_USER with your container registry username.
If you're using Container Registry or Artifact Registry and would like to store and pull long-lived credentials instead of passing short-lived access tokens, see Authentication methods: JSON key file.
Replace REGISTRY_PASSWORD with your container registry password.
Open your default service account:
kubectl edit serviceaccount default --namespace default
Every namespace in your Kubernetes cluster has a default service account called
default
. This default service account is used to pull your container image unless otherwise specified when you deploy your Knative serving service.Add the newly created
imagePullSecret
secret to your default service account:imagePullSecrets: - name: container-registry
Your service account should now look like this:
apiVersion: v1 kind: ServiceAccount metadata: name: default namespace: default ... secrets: - name: default-token-zd84v # The secret we just created: imagePullSecrets: - name: container-registry
Now, any new pods created in the current default
namespace will have the
imagePullSecret
secret defined.
Deploying with automatic sidecar injection enabled
To deploy your service with Istio sidecar injection enabled, see automatic sidecar injection enabled in the Cloud Service Mesh documentation.
Deploying services on an internal network
To deploy services on an internal network, you must set up a private, internal network.
What's next
After you deploy a new service, you can do the following:
- Gradual rollouts, rollback revisions, traffic migration
- View service logs
- Monitor service performances
- Configure your services. For example, set memory limits, set environment variables, or change concurrency.
- Manage:
You can automate the builds and deployments of your Knative serving services using Cloud Build Triggers: