GKE での Cloud Endpoints のトラブルシューティング

このドキュメントでは、Google Kubernetes Engine(GKE)と Kubernetes での Endpoints のデプロイに関するトラブルシューティング方法について説明します。

kubectl create -f gke.yaml のエラー

Failed in kubectl create -f gke.yaml」というエラー メッセージが表示されたら、次の操作を行います。

  1. gcloud を承認します。

    gcloud auth login
    gcloud auth application-default login
    
  2. クラスタを作成します。次の gcloud コマンドを使用することも、Google Cloud Platform Console を使用してクラスタを作成することもできます。

    gcloud container clusters create CLUSTER_NAME
    

    CLUSTER_NAME をクラスタの名前で置き換えます。

  3. クラスタの認証情報を取得し、kubectl で使用可能にします。

    gcloud container clusters get-credentials CLUSTER_NAME
    

Endpoints の指標とログが表示されない

API にリクエストを正常に送信できたものの、GCP Console の [Endpoints] > [サービス] ページに指標またはログが表示されない場合は、次のようにして、必要な OAuth スコープがクラスタに設定されているかどうかを確認します。

  1. GCP Console で Kubernetes クラスタのページに移動します。

    [Kubernetes クラスタ] ページに移動

  2. リストから該当するクラスタを選択します。

  3. [権限] をクリックします。

  4. サービス コントロールとサービス管理に次の OAuth スコープが設定されていることを確認します。

    • サービス コントロール: 有効
    • サービス管理: 読み取り専用

    サービス コントロールとサービス管理に必要な OAuth スコープが設定されていない場合は、必要なスコープで別のクラスタを作成するか、ゼロ ダウンタイムで GKE VM スコープを更新するの手順に従います。

    詳細については、アクセス スコープの概要をご覧ください。

Extensible Service Proxy ログにアクセスする

問題を診断するために Extensible Service Proxy(ESP)ログにアクセスする必要がある場合は、次のように kubectl を使用します。

  1. ポッドの名前を取得します。

    kubectl get pod
    
    NAME                       READY     STATUS    RESTARTS   AGE
    esp-echo-174578890-x09gl   2/2       Running   2          21s
    

    ポッド名は esp-echo-174578890-x09gl で、especho の 2 つのコンテナがあります。

  2. ポッドのログを表示するには、kubectl logs を使用します。

    kubectl logs POD_NAME -c CONTAINER_NAME
    

    ここで、POD_NAMECONTAINER_NAME は、前のステップの kubectl get pod コマンドから返されます。次に例を示します。

      kubectl logs esp-echo-174578890-x09gl -c esp
    

サービス名を確認する

Fetching service config failed」というエラー メッセージが返された場合は、Deployment マニフェスト ファイル(次の例では deployment.yaml)の --service フィールドで指定したサービス名が、OpenAPI ドキュメント(次の例では openapi.yaml)の host フィールドの名前と一致していることを確認します。

deployment.yaml ファイルに誤った名前が指定されている場合:

  1. deployment.yaml ファイルを開き、ESP コンテナ用に構成されたセクションに進みます。次に例を示します。

    containers:
    - name: esp
      image: gcr.io/endpoints-release/endpoints-runtime:1
      args: [
        "--http_port=8081",
        "--backend=127.0.0.1:8080",
        "--service=SERVICE_NAME",
        "--rollout_strategy=managed"
      ]
    

    openapi.yamlhost フィールド内の名前と一致するように SERVICE_NAME を変更して、deployment.yaml ファイルを保存します。

  2. Kubernetes サービスを起動します。

      kubectl create -f deployment.yaml
    

openapi.yaml ファイルに誤った名前が指定されている場合:

  1. Endpoints で使用するように構成されていたサービス名を取得します

  2. サービスを削除します。

    gcloud endpoints services delete SERVICE_NAME
    

    SERVICE_NAME は、前のステップで取得した名前に置き換えます。サービスが GCP から削除されるまでに 30 日かかります。この間に同じサービス名を再利用することはできません。

  3. openapi.yaml ファイルを開き、host フィールドの名前を訂正してファイルを保存します。

  4. 更新されたサービス構成をデプロイします。

      gcloud endpoints services deploy openapi.yaml
    
  5. サービス構成のデプロイが正常に完了するまで待ちます。

  6. Kubernetes サービスを起動します。

      kubectl create -f deployment.yaml
    

構成ファイルを確認する

  1. kubectl を使用してポッドに接続するには、ssh を使用します。

    kubectl exec -ti -c CONTAINER_NAME POD_NAME bash
    

    CONTAINER_NAME をコンテナの名前に、POD_NAME をポッドの名前に置き換えます。

  2. etc/nginx/endpoints/ ディレクトリで、以下の構成ファイルにエラーがないか調べます。

    • nginx.conf - ESP ディレクティブを含む nginx 構成ファイル
    • service.jso - サービス構成ファイル

Endpoints ステータス ページを表示する

ESP の起動時に rollout_strategymanaged に設定しており、ESP インスタンスが使用している構成 ID を確認する必要がある場合は、Endpoints ステータス ページに情報があります。

Endpoints ステータス ページにアクセスするには:

  1. kubectl を使用してポッドに接続するには、ssh を使用します。

    kubectl exec -ti -c CONTAINER_NAME POD_NAME bash
    

    CONTAINER_NAME をコンテナの名前に、POD_NAME をポッドの名前に置き換えます。

  2. curl をインストールします。

  3. 次のように入力します。

      curl http://localhost:8090/endpoints_status
    

    次のような内容が表示されます。

    "serviceConfigRollouts": {
        "rolloutId": "2017-08-09r27",
        "percentages": {
             "2017-08-09r26": "100"
        }
    }
    

rolloutId の値は、ESP が使用しているサービス構成 ID です。ESP が Endpoints と同じ構成を使用するようにするには、サービス名と構成 ID の取得をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

OpenAPI を使用した Cloud Endpoints
ご不明な点がありましたら、Google のサポートページをご覧ください。