Getting started with Endpoints for Kubernetes with ESP

Configuring Endpoints

The bookstore-grpc sample contains the files that you need to copy locally and configure.

1. Create a self-contained protobuf descriptor file from your service .proto file:
   1. Save a copy of bookstore.proto from the example repository. This file defines the Bookstore service's API.
   2. Create the following directory: mkdir generated_pb2
   3. Create the descriptor file, api_descriptor.pb , by using the protoc protocol buffers compiler. Run the following command in the directory where you saved bookstore.proto :

       python 
        
       - 
       m 
        
       grpc_tools 
       . 
       protoc 
        
      \  
       -- 
       include_imports 
        
      \  
       -- 
       include_source_info 
        
      \  
       -- 
       proto_path 
       =. 
        
      \  
       -- 
       descriptor_set_out 
       = 
       api_descriptor 
       . 
       pb 
        
      \  
       -- 
       python_out 
       = 
       generated_pb2 
        
      \  
       -- 
       grpc_python_out 
       = 
       generated_pb2 
        
      \  
       bookstore 
       . 
       proto 
      

      In the preceding command, --proto_path is set to the current working directory. In your gRPC build environment, if you use a different directory for .proto input files, change --proto_path so the compiler searches the directory where you saved bookstore.proto .

2. Create a gRPC API configuration YAML file:
   1. Save a copy of the api_config.yaml file . This file defines the gRPC API configuration for the Bookstore service.
   2. Replace MY_PROJECT_ID in your api_config.yaml file with your Google Cloud project ID. For example:

      #
      # Name of the service configuration.
      #
      name: bookstore.endpoints. example-project-12345.cloud.goog

      Note that the apis.name field value in this file exactly matches the fully-qualified API name from the .proto file; otherwise deployment won't work. The Bookstore service is defined in bookstore.proto inside package endpoints.examples.bookstore . Its fully-qualified API name is endpoints.examples.bookstore.Bookstore , just as it appears in the api_config.yaml file.

      apis:
        - name: endpoints.examples.bookstore.Bookstore

See Configuring Endpoints for more information.

Deploying the Endpoints configuration

To deploy the Endpoints configuration, you use the gcloud endpoints services deploy command. This command uses Service Infrastructure , Google's foundational services platform, used by Endpoints and other services to create and manage APIs and services.

1. Make sure you are in the directory where the api_descriptor.pb and api_config.yaml files are located.
2. Confirm that the default project that the gcloud command-line tool is currently using is the Google Cloud project that you want to deploy the Endpoints configuration to. Validate the project ID returned from the following command to make sure that the service doesn't get created in the wrong project.

   gcloud config list project

   If you need to change the default project, run the following command:

   gcloud config set project YOUR_PROJECT_ID 
   

3. Deploy the proto descriptor file and the configuration file by using the Google Cloud CLI:

   gcloud endpoints services deploy api_descriptor.pb api_config.yaml

   As it is creating and configuring the 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 [bookstore.endpoints.example-project.cloud.goog]

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

   Service Configuration [2017-02-13r0] uploaded for service [bookstore.endpoints.example-project.cloud.goog]

   In the previous example, 2017-02-13r0 is the service configuration ID and bookstore.endpoints.example-project.cloud.goog is the service name. The service configuration ID consists of a date stamp followed by a revision number. If you deploy the Endpoints configuration again on the same day, the revision number is incremented in the service configuration ID.

Checking required services

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 

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 Endpointspage in the Cloud console. The list of possible ENDPOINTS_SERVICE_NAME are shown under the Service namecolumn.

• 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 .

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

See Deploying the Endpoints configuration for additional information.

Creating credentials for your service

To provide management for your API, both ESP and ESPv2 require the services in Service Infrastructure . To call these services, ESP and ESPv2 must use access tokens. When you deploy ESP or ESPv2 to Google Cloud environments, such as GKE or Compute Engine, ESP and ESPv2 obtain access tokens for you through the Google Cloud metadata service.

When you deploy ESP or ESPv2 to a non-Google Cloud environment, such as your local desktop, an on-premises Kubernetes cluster, or another cloud provider, you must provide a service account JSON file that contains a private key. ESP and ESPv2 use the service account to generate access tokens to call the services that it needs to manage your API.

You can use either the Google Cloud console or the Google Cloud CLI to create the service account and private key file:

Add required IAM roles:

This section describes the IAM resources used by ESP and ESPv2 and the IAM roles required for the attached service account to access these resources.

Endpoint Service Configuration

ESP and ESPv2 call Service Control which uses the endpoint service configuration. The endpoint service configuration is an IAM resource and ESP and ESPv2 need the Service Controller role to access it.

The IAM role is on the endpoint service configuration, not on the project. A project may have multiple endpoint service configurations.

Use the following gcloud command to add the role to the attached service account for the endpoint service configuration.

gcloud endpoints services add-iam-policy-binding SERVICE_NAME 
\
  --member serviceAccount: SERVICE_ACCOUNT_NAME 
@ DEPLOY_PROJECT_ID 
.iam.gserviceaccount.com \
  --role roles/servicemanagement.serviceController

Where
* SERVICE_NAME is the endpoint service name
* SERVICE_ACCOUNT_NAME @ DEPLOY_PROJECT_ID .iam.gserviceaccount.com is the attached service account.

Cloud Trace

ESP and ESPv2 call Cloud Trace service to export Trace to a project. This project is called the tracing project. In ESP, the tracing project and the project that owns the endpoint service configuration are the same. In ESPv2, the tracing project can be specified by the flag --tracing_project_id , and defaults to the deploying project.

ESP and ESPv2 require the Cloud Trace Agent role to enable Cloud Trace.

Use the following gcloud command to add the role to the attached service account:

gcloud projects add-iam-policy-binding TRACING_PROJECT_ID 
\
  --member serviceAccount: SERVICE_ACCOUNT_NAME 
@ DEPLOY_PROJECT_ID 
.iam.gserviceaccount.com \
  --role roles/cloudtrace.agent

Where
* TRACING_PROJECT_ID is the tracing project ID
* SERVICE_ACCOUNT_NAME @ DEPLOY_PROJECT_ID .iam.gserviceaccount.com is the attached service account. For more information, see What are roles and permissions?

See gcloud iam service-accounts for more information about the commands.

Deploying the API backend

So far you have deployed the service configuration to Service Management, but you have not yet deployed the code that serves the API backend. This section walks you through deploying prebuilt containers for the sample API and ESP to Kubernetes.

Providing ESP with the service credentials

ESP, which runs inside a container, needs access to the credentials stored locally in the service-account-creds.json file. To provide ESP with access to the credentials, you create a Kubernetes secret and mount the Kubernetes secret as a Kubernetes volume .

To create the Kubernetes secret and mount the volume:

1. If you used the Google Cloud console to create the service account, rename the JSON file to service-account-creds.json . Move it to the same directory where the api_descriptor.pb and api_config.yaml files are located.

2. Create a Kubernetes secret with the service account credentials:

   kubectl create secret generic service-account-creds
         --from-file=service-account-creds.json

   On success, you see the message, secret "service-account-creds" created .

The deployment manifest file that you use to deploy the API and ESP to Kubernetes already contains the secret volume , as shown in the following two sections of the file:

  volumes 
 : 
  
 - 
  
 name 
 : 
  
 service-account-creds 
  
 secret 
 : 
  
 secretName 
 : 
  
 service-account-creds 
 

  volumeMounts 
 : 
  
 - 
  
 mountPath 
 : 
  
 /etc/nginx/creds 
  
 name 
 : 
  
 service-account-creds 
  
 readOnly 
 : 
  
 true 
 

Configuring the service name and starting the service

ESP needs to know the name of your service to find the configuration that you deployed previously by using the gcloud endpoints services deploy command.

To configure the service name and start the service:

1. Save a copy of the deployment manifest file, k8s-grpc-bookstore.yaml , to the same directory as service-account-creds.json .

2. Open k8s-grpc-bookstore.yaml and replace SERVICE_NAME with the name of your Endpoints service. This is the same name that you configured in the name field of the api_config.yaml file.

     containers 
    : 
     
    - 
     
    name 
    : 
     
    esp 
     
    image 
    : 
     
    gcr.io/endpoints-release/endpoints-runtime:1 
     
    args 
    : 
     
    [ 
     
    "--http2_port=9000" 
    , 
     
    "--service=SERVICE_NAME" 
    , 
     
    "--rollout_strategy=managed" 
    , 
     
    "--backend=grpc://127.0.0.1:8000" 
    , 
     
    "--service_account_key=/etc/nginx/creds/service-account-creds.json" 
     
    ] 
    
   

   The --rollout_strategy=managed option configures ESP to use the latest deployed service configuration. When you specify this option, up to 5 minutes after you deploy a new service configuration, ESP detects the change and automatically begins using it. We recommend that you specify this option instead of a specific configuration ID for ESP to use. For more details on the ESP arguments, see ESP startup options .

3. Start the service to deploy the service on Kubernetes:

   kubectl create -f k8s-grpc-bookstore.yaml

   If you see an error message similar to the following:

   The connection to the server localhost:8080 was refused - did you specify the right host or port?

   This indicates that kubectl isn't properly configured. See Configure kubectl for more information.

Getting the service's external IP address

You need the service's external IP address to send requests to the sample API. It can take a few minutes after you start your service in the container before the external IP address is ready.

1. View the external IP address:

   kubectl get service

2. Make a note of the value for EXTERNAL-IP and save it in a SERVER_IP environment variable as it used when sending requests to the sample API.

   export SERVER_IP= YOUR_EXTERNAL_IP 
   

Sending a request to the API

To send requests to the sample API, you can use a sample gRPC client written in Python.

1. Clone the git repo where the gRPC client code is hosted:

   git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git

2. Change your working directory:

   cd python-docs-samples/endpoints/bookstore-grpc/

3. Install dependencies:

    pip install virtualenv 
    virtualenv env 
    source env/bin/activate 
    python -m pip install -r requirements.txt 
   

4. Send a request to the sample API:

   python bookstore_client.py --host SERVER_IP 
   --port 80

   • Look at the activity graphs for your API in the Endpoints> Servicespage.
     

     Go to the Endpoints Services page

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

   • Look at the request logs for your API in the Logs Explorer page.
     

     Go to the Logs Explorer page

If you don't get a successful response, see Troubleshooting response errors .

You just deployed and tested an API in Endpoints!