Set up Cloud Endpoints OpenAPI for Knative serving with ESPv2

Set up Cloud Endpoints OpenAPI for Knative serving with ESPv2

OpenAPI   |  gRPC

This page shows you how to set up Cloud Endpoints for Knative serving. Endpoints uses the Extensible Service Proxy V2 (ESPv2) as an API gateway. To provide API management for Knative serving, you deploy the prebuilt ESPv2 container to Knative serving running on a GKE cluster.

With this set up, ESPv2 intercepts all requests to your services and performs any necessary checks (such as authentication) before invoking the service. When the service responds, ESPv2 gathers and reports telemetry.

For an overview of Endpoints, see About Endpoints and Endpoints architecture.

Task List

Use the following task list as you work through the tutorial. All tasks are required to complete this tutorial.

1. Create a Google Cloud project, and if you haven't deployed your own Knative serving, deploy a sample service. See Before you begin.

2. Create a GKE cluster with Knative serving enabled.

3. Deploy a sample Knative serving service.

4. Create an OpenAPI document that describes your Endpoints API, and configure the routes to your Knative serving service. See Configuring Endpoints.

5. Deploy the OpenAPI document to create a managed service. See Deploying the Endpoints configuration.

6. Build a new ESPv2 Docker image with your Endpoints service configuration. See Building a new ESPv2 image.

7. Deploy the new ESPv2 Knative serving image. See Deploying the ESPv2 Cloud Run image.

8. Create a domain mapping to the ESPv2 Knative serving service.

9. Test your configuration by Sending a request to the API.

10. Track activity to your services. See Tracking API activity.

11. Clean up.

Costs

In this document, you use the following billable components of Google Cloud:

• Knative serving
• Endpoints

To generate a cost estimate based on your projected usage, use the pricing calculator. New Google Cloud users might be eligible for a free trial.

When you finish the tasks that are described in this document, you can avoid continued billing by deleting the resources that you created. For more information, see Clean up.

Before you begin

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Make a note of the project ID because it is needed later. On the rest of this page, this project ID is referred to as ESP_PROJECT_ID.
7. Download and install the Google Cloud SDK.
8. Install cURL if you want to send a request to the deployed sample service.

Setting up the gcloud command line

To set up the gcloud CLI for Knative serving for Anthos:

1. Make sure that Google Cloud SDK is authorized to access your data and services.

   1. Log in.

      gcloud auth login

   2. On the new browser tab that opens, choose an account that has the Editor or Owner role in the Google Cloud project that you created for deploying ESPv2 to Knative serving.

2. Update installed gcloud components:

   gcloud components update

3. Set the platform to gke and set your default project setting for gcloud to the one you just created:

   gcloud config set run/platform gke 
   gcloud config set project ESP_PROJECT_ID

   Replace ESP_PROJECT_ID with the project ID of the project you created.

4. Set the desired zone for the new cluster. You can use any zone where GKE is supported, for example:

   gcloud config set compute/zone ZONE

   Replace ZONE with your zone. For example, use us-central1-a. You can use any zone supported by GKE.

5. Enable the following APIs for the project, which are needed to create a cluster, build and publish a container into the Artifact Registry:

   gcloud services enable container.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com

Creating a GKE cluster with Knative serving enabled

To create a cluster and enable it for Knative serving on Google Cloud:

1. Create a new cluster using the command:

   gcloud container clusters create CLUSTER_NAME \ 
     --addons=HttpLoadBalancing,CloudRun \ 
     --machine-type=n1-standard-4 \ 
     --num-nodes=3 \ 
     --enable-stackdriver-kubernetes

   Replace CLUSTER_NAME with the name you want for your cluster.

   Note: The minimum cluster size is three nodes and the minimum machine type is n1-standard-4 for this example.

   Although these instructions don't enable cluster autoscaling to resize clusters for demand, Knative serving on Google Cloud automatically scales instances within the cluster.

2. Wait for the cluster creation to complete. During the creation process, you should see messages similar to the following:

   Creating cluster CLUSTER_NAME...done. 
   Created [https://container.googleapis.com/v1/projects/ESP_PROJECT_ID/zones/ZONE/clusters/CLUSTER_NAME].

   The output also shows the cluster version under the NODE_VERSION column of the output. For example, 1.15.11-gke.1 or 1.14.10-gke.27. Make note of the cluster version for use later in this document.

3. Set gcloud defaults to use your new cluster and cluster location, to avoid having to specify these when you use the gcloud CLI:

   gcloud config set run/cluster CLUSTER_NAME
   gcloud config set run/cluster_location ZONE

4. Use the following command to view details about the new cluster:

   gcloud container clusters describe CLUSTER_NAME

5. Use the following command to fetch credentials for your cluster:

   gcloud container clusters get-credentials CLUSTER_NAME

Deploying a sample Knative serving container

To deploy the "hello" Knative serving sample container to the cluster you just created:

1. Go to Cloud Run

2. Click Create service.

3. Select Knative serving as your development platform.

4. In the available clusters dropdown menu, select the cluster you just created.

5. Use the name hello as the Service name. You can use some other name, but if you do, make sure you use that name later. These instructions assume you use hello.

6. Select Internal under Connectivity so that the service is not externally accessible.

7. Click Next to continue to the second page of the service creation form.

8. Specify gcr.io/cloudrun/hello as the Container image URL.

9. Click Create to deploy the image to Knative serving and wait for the deployment to finish.

   When you are done, the Revisions screen appears. Note that the URL of the deployed service is:

   http://hello.default.svc.cluster.local

   When you create an Internal service, GKE creates a DNS name that can only be resolved for requests originating from within the cluster itself, not for external requests. You cannot access this link externally from the cluster. See Cloud Run services for more.

10. To verify that your service is working correctly using cURL, set up a tunnel from your desktop to the cluster. To see these instructions, click the icon to the right of the URL on the Revisions screen:

    

11. A panel opens showing the two commands that you use to access the internal service. You must run these commands in two separate terminal windows because the first command sets up port forwarding that is used by the second command.

    When you run the cURL command, you should see output from your service in the form:

    <!doctype html>
    <html lang=en> 
    <head> 
    <meta charset=utf-8> 
    <meta name="viewport" content="width=device-width, initial-scale=1"> 
    <title>Congratulations | Cloud Run</title> 
    ...

Configuring Endpoints

You must have an OpenAPI document based on OpenAPI Specification v2.0 that describes the surface of your backend service and any authentication requirements. You also need to add a Google-specific field that contains the URL for each service so that ESPv2 has the information it needs to invoke a service. If you are new to OpenAPI, see OpenAPI overview for more information.

About setting the host field of the OpenAPI spec

In the host field of the OpenAPI spec, you specify the Endpoints service name used to access your Knative serving service. The Endpoints service name is in the form of a domain name:

API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog

Because the Endpoints service name corresponds to a domain name, the name must follow these rules:

• Must contain only lowercase letters, numbers, periods, or dashes.
• Must not start with a dash.
• Must not contain an underscore.

For example:

hello-api.endpoints.ESP_PROJECT_ID.cloud.goog

Creating the OpenAPI spec

1. Create a text file called openapi-run-anthos.yaml.

2. Your Knative serving backend service is defined at the top of the openapi-run-anthos.yaml file, in an x-google-backend definition. For example:

   swagger: '2.0' 
   info:
     title: Cloud Endpoints + Cloud Run
     description: Sample API on Cloud Endpoints with a Cloud Run backend
     version: 1.0.0 
   host: API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog
   x-google-endpoints:
   - name: API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog
     target: "INGRESS-IP"
   schemes:
     - https
   produces:
     - application/json
   x-google-backend:
     address: http://hello.default.svc.cluster.local
     disable_auth: true
   paths:
     /hello:
       get:
         summary: Greet a user
         operationId: hello
         responses:
           '200':
             description: A successful response
             schema:
               type: string

   Indentation is important for YAML format. For example the host field must be at the same level as info.

3. In the host field, specify the domain name of the Endpoints API used to access your Knative serving service, in the form:

   API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog

   For example:

   hello-api.endpoints.ESP_PROJECT_ID.cloud.goog

4. The x-google-endpoints extension registers a DNS entry for your Endpoints service on the cloud.goog domain, in the form:

   x-google-endpoints: 
     - name: "API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog"
     target: "IP_ADDRESS"

   Note: If you have your own domain mapping defined for your cluster, you can omit this step. See Configuring DNS on the cloud.goog domain for more.

   The IP_ADDRESS is the IP of the istio-ingress service for your cluster. To determine this IP address:

   1. Go to the Google Kubernetes Engine page in the Google Cloud console:

      Go to Google Kubernetes Engine

   2. Click Services & Ingress in the left navigation panel to display a list of services.

   3. If your cluster version is 1.15.3-gke.19 or greater, 1.14.3-gke.12 or greater, or 1.13.10-gke.8 or greater, scroll down to the istio-ingress service. For all other cluster versions, scroll down to the istio-ingressgateway service.

   4. Copy the external IP address shown next to the Load Balancer, without the port setting, if there is one. For example, if the IP is XX.XXX.XX.XXX:15020, omit the :15020. Ignore the other IP addresses listed.

5. In the address field in the x-google-backend section, specify the internal DNS name of the backend Knative serving "hello" service, and disable authentication to this service. This is necessary because the call from ESPv2 to the Knative serving service is made as an internal call from within the cluster and therefore authentication is not necessary.

6. Note the value of the title property in the openapi-run-anthos.yaml file:

   title: Cloud Endpoints + Cloud Run 

7. The value of the title property becomes the name of the Endpoints service after you deploy the configuration.

8. Save your OpenAPI document.

For information about the fields in the OpenAPI document that Endpoints requires, see Configuring Endpoints.

Deploying the Endpoints configuration

To deploy the Endpoints configuration, you use the gcloud endpoints services deploy command. This command uses Service Management to create a managed service.

To deploy the Endpoints configuration:

1. Make sure you are in the directory that contains your OpenAPI document.

2. Upload the configuration and create a managed service.

   gcloud endpoints services deploy openapi-run-anthos.yaml \ 
     --project ESP_PROJECT_ID

   This creates a new Endpoints service with the name that you specified in the host field of the openapi-run-anthos.yaml file. The Endpoints service is configured according to your OpenAPI document.

   As it is creating and configuring the Endpoints service, Service Management outputs information to the terminal. When the deployment completes, a message similar to the following is displayed:

   Service Configuration [CONFIG_ID] uploaded for service [API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog]

   CONFIG_ID is the unique Endpoints service configuration ID created by the deployment. For example:

   Service Configuration [2019-02-01r0] uploaded for service [hello-api.endpoints.ESP_PROJECT_ID.cloud.goog] 

   The service configuration ID consists of a date stamp followed by a revision number. If you deploy openapi-run-anthos.yaml again on the same day, the revision number is incremented in the service configuration ID. You can view the service configuration and the deployment history on the Endpoints > Services page in the Google Cloud console.

   If you get an error message, see Troubleshooting Endpoints configuration deployment.

Checking required services

At a minimum, Endpoints and ESP require the following Google services to be enabled:

Name	Title
servicemanagement.googleapis.com	Service Management API
servicecontrol.googleapis.com	Service Control API
endpoints.googleapis.com	Google Cloud Endpoints

In most cases, the gcloud endpoints services deploy command enables these required services. However, the gcloud command completes successfully but doesn't enable the required services in the following circumstances:

• If you used a third-party application such as Terraform, and you don't include these services.

• You deployed the Endpoints configuration to an existing Google Cloud project in which these services were explicitly disabled.

Use the following command to confirm that the required services are enabled:

gcloud services list

If you do not see the required services listed, enable them:

gcloud services enable servicemanagement.googleapis.com
gcloud services enable servicecontrol.googleapis.com
gcloud services enable endpoints.googleapis.com

Also enable your Endpoints service:

gcloud services enable ENDPOINTS_SERVICE_NAME

To determine the ENDPOINTS_SERVICE_NAME you can either:

• After deploying the Endpoints configuration, go to the Endpoints page in the Cloud console. The list of possible ENDPOINTS_SERVICE_NAME are shown under the Service name column.

• For OpenAPI, the ENDPOINTS_SERVICE_NAME is what you specified in the host field of your OpenAPI spec. For gRPC, the ENDPOINTS_SERVICE_NAME is what you specified in the name field of your gRPC Endpoints configuration.

For more information about the gcloud commands, see gcloud services.

Building a new ESPv2 Knative serving image

Build the Endpoints service config into a new ESPv2 docker image. After creating this image, you can deploy it to your cluster.

Note:

This step is required.

The service config must be built into a new docker image because Cloud Run is a scale-to-zero service. That means when there is no traffic, all instances are deleted. When traffic increases, new instances are created on-demand. This type of service instance creation is also called cold start. See the Cloud Run Concurrency documentation for more.

If the docker image did not have the service config built into it, Cloud Run would have to make two API calls to Google ServiceManagement at cold start. These calls count against your Google ServiceManagement API quota.

By building the service config into the ESPv2 docker image, you remove the two API calls and avoid impacting the quota count for the Google ServiceManagement service. This step also speeds up the new service instance creation and reduces the latency for the requests waiting for the new instance.

You must re-run this entire step and redeploy the new container:

• Every time you modify and redeploy the Endpoints service configuration. Otherwise, changes to the service configuration will not be propagated to ESPv2.
• When a new version of ESPv2 is released. Otherwise, the older version of ESPv2 will remain deployed.

To build the service config into a new ESPv2 docker image:

1. Download this script to your local machine where the gcloud CLI is installed and run it as:

   chmod +x gcloud_build_image
   ./gcloud_build_image -s API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog \ 
   -c CONFIG_ID -p ESP_PROJECT_ID

   Note: This script requires bash. If you are not using macOS/Linux, you can run it on Cloud Shell, Compute Engine, or Windows Subsystem for Linux.

   The script uses the gcloud command to download the service config, build the service config into a new ESPv2 image, and upload the new image to your project container registry. The script automatically uses the latest release of ESPv2, denoted by the ESP_VERSION in the output image name. The output image is uploaded to:

   gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:ESP_VERSION-API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID

Deploying the ESPv2 Knative serving image

Deploy the ESPv2 Knative serving service image to your cluster:

1. Deploy the ESPv2 Knative serving service with the new image:

   gcloud run deploy ESP_V2_SERVICE_NAME \ 
     --image="gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:ESP_VERSION-API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID" \ 
     --platform gke \ 
     --project=ESP_PROJECT_ID

   For ESP_PROJECT_ID specify the name that you want to use for the ESPv2 service. In this example, set ESP_V2_SERVICE_NAME to espv2.

2. If you want to configure Endpoints to use additional ESPv2 startup options, such as enabling CORS, you can pass the arguments in the ESPv2_ARGS environment variable:

   gcloud run deploy ESP_V2_SERVICE_NAME \
     --image="gcr.io/ESP_PROJECT_ID/endpoints-runtime-serverless:ESP_VERSION-API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog-CONFIG_ID" \ 
     --set-env-vars=ESPv2_ARGS=--cors_preset=basic \ 
     --platform gke \ 
     --project ESP_PROJECT_ID

   For more information and examples on setting the ESPv2_ARGS environment variable, including the list of available options and information on how to specify multiple options, see Extensible Service Proxy V2 flags.

The ESPv2 service is deployed as an external service, which means you can access it by using a cURL command in the form:

curl -H "Host: espv2.default.example.com" http://IP_ADDRESS

where IP_ADDRESS is the IP address of the istio-ingress service for your cluster.

To see this cURL command, click the IMAGE icon to the right of the ESPv2 URL on the Revisions screen of the deployed ESPv2 Knative serving service.

You can now make API calls to your Endpoints service through the ESPv2 service. For example, to make a request to an Endpoints service with a path of /hello, you could make a request in the form:

curl -H "Host: espv2.default.example.com" http://IP_ADDRESS/hello

However, specifying a host header on every request to your Endpoints service is not user-friendly. In the next section, you set up a domain map to make it easier to make a call to your Endpoint service through ESPv2.

Creating a domain mapping to the ESPv2 Knative serving service

To be able to omit the host header when you make a request, add a domain mapping for the ESPv2 service:

1. Go to Cloud Run

2. Select Manage Custom Domains.

3. Select Add Mapping.

4. From the dropdown, select Add service domain mapping.

5. In the Select a service to map to field of the Add mapping popup, select your ESPv2 service.

6. In the Enter domain name field, specify the domain name you want to use to access your Knative serving service through Endpoints. For example, specify:

   API_NAME.endpoints.ESP_PROJECT_ID.cloud.goog

   Where API_NAME is the name of your Endpoints API. For this example, you can use "hello-api":

   hello-api.endpoints.ESP_PROJECT_ID.cloud.goog

7. Click Continue. A summary of the mapping appears.

8. Select Done to save the mapping.

Sending requests to the API

Use cURL to send an HTTP request to your API:

curl -X GET "http://hello-api.endpoints.ESP_PROJECT_ID.cloud.goog/hello"

If you didn't get a successful response, see Troubleshooting Response Errors.

Configuring Endpoints API to use HTTPS

Automatic TLS support is disabled by default for Knative serving on Google Cloud. Therefore, in this example when you access your Endpoints API through ESPv2, you make the call using HTTP.

You can configure ESPv2 to support requests using HTTPS. Note that you configure HTTPS support on ESPv2, the external service, not on "hello", the internal backend service.

To support HTTPS with ESPv2, you must:

1. Own a domain. If you don't have a domain, you can obtain one from Cloud Domains or from another domain vendor.

2. Create a domain mapping for your ESPv2 service and have updated your DNS record accordingly following the instructions at the domains mapping page.

   If you obtained your domain from Cloud Domains, use Cloud DNS, or a DNS server of your choice. Using a domain from Cloud Domains is the easiest option.

3. In the Endpoints OpenAPI spec:

   1. Set the host field to refer to your domain instead of to *.cloud.goog.

   2. Remove the x-google-endpoints tag and its two child properties.

For complete instructions and tutorial, see Enabling HTTPS and automatic TLS certificates.

Note: If you want to let us know what you liked about this tutorial, feel free to provide feedback at the bottom of this page. Your feedback helps us improve these tutorials.
If you got an error, join the google-cloud-endpoints Google group and let us know what went wrong. This group receives responses from other Endpoints users and from Google engineers, who monitor the group.

Tracking API activity

1. View the activity graphs for your API on the Endpoints > Service page in the Google Cloud console.

   View Endpoints activity graphs

   It may take a few moments for the request to be reflected in the graphs.

2. Look at the request logs for your API on the Logs Explorer page. View Endpoints request logs

Creating a developer portal for the API

You can use Cloud Endpoints Portal to create a developer portal, a website that you can use to interact with the sample API. To learn more, see Cloud Endpoints Portal Overview.

Clean up

To avoid incurring charges to your Google Cloud account for the resources used on this page, follow these steps.

See Deleting an API and API instances for information on stopping the services used by this tutorial.

What's next

• Learn more about Cloud Run
• Learn more about deploying the Endpoints configuration
• Share your API with another developer
• Learn about authentication
• Learn about community support options