概要

このラボでは、コマンドラインを使用した GKE クラスタの構築と kubeconfig ファイルの検査を行い、クラスタの操作に kubectl を使用します。

目標

このラボでは、次のタスクについて学びます。

• kubectl を使用して GKE クラスタを構築し、操作する
• kubectl と構成ファイルを使用して Pod をデプロイする
• Container Registry を使用してコンテナを保存し、デプロイする

ラボの設定

Qwiklabs にアクセスする

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。

Cloud Shell を開く

ほとんどの作業は、Cloud Shell で行います。Cloud Shell は Google Cloud 上で動作するコマンドライン環境です。Debian ベースの仮想マシンであり、必要となるすべての管理ツール（docker、gcloud、gsutil、kubectl など）と、永続的な 5 GB のホーム ディレクトリが用意されています。

1. Google Cloud コンソールのタイトルバーで、Cloud Shell をアクティブにするアイコン（）をクリックします。
2. [続行] をクリックします。

プロビジョニングされると、Cloud Shell プロンプトが表示されます。

タスク 1. GKE クラスタをデプロイする

このタスクでは、Cloud Shell を使用して GKE クラスタをデプロイします。

1. Cloud Shell で次のコマンドを入力して、ゾーンとクラスタ名の環境変数を設定します。

export my_region={{{project_0.default_region|Region}}} export my_cluster=autopilot-cluster-1

2. Cloud Shell で次のコマンドを入力して、Kubernetes クラスタを作成します。

gcloud container clusters create-auto $my_cluster --region $my_region

この形式のコマンドでは、ほとんどのオプションがデフォルトに設定されます。有効なオプションの一覧については、gcloud container clusters create リファレンスをご覧ください。

いくつかの警告が表示され、デフォルトの GKE クラスタ設定の変更箇所が示されます。これらは、新しいバージョンの Kubernetes が GKE で採用されたときに導入されたものです。

注: クラスタのデプロイが完了するまで数分待つ必要があります。

デプロイが完了すると、Google Cloud コンソールの [Kubernetes Engine] > [クラスタ] ページは、次のスクリーンショットのようになります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 GKE クラスタをデプロイする

タスク 2. GKE クラスタに接続する

このタスクでは、Cloud Shell を使用して GKE クラスタに対する認証を行ってから、kubectl 構成ファイルの内容を確認します。

Kubernetes での認証は、マスター上で動作している kube-APIserver を介した外部クライアントからクラスタへの通信と、クラスタ内または外部でのクラスタ コンテナの通信の両方に適用されます。

Kubernetes での認証にはいくつかの形式があります。GKE の場合、通常は OAuth2 トークンで認証が処理され、Cloud Identity and Access Management を使用してプロジェクト全体で認証を管理できます。各クラスタ内で定義して構成できる、ロールベースのアクセス制御を使用することもできます。

GKE では、クラスタ コンテナでサービス アカウントを使用して、外部リソースに対する認証とアクセスを行うことができます。

注: 1.12 よりも前のバージョンの Kubernetes では、クライアント証明書と基本認証がデフォルトで無効になっていません。これらは安全性の低い認証方法であるため、クラスタのセキュリティを強化するために無効にする必要があります（1.12 以降のバージョンでは、これらは両方ともデフォルトで無効になっています）。

1. 現在のユーザーの認証情報で kubeconfig ファイルを作成（認証を許可）し、特定のクラスタのエンドポイント情報を提供（kubectl コマンドライン ツールを介した対象クラスタとの通信を許可）するには、次のコマンドを実行します。

gcloud container clusters get-credentials $my_cluster --region $my_region

ホーム ディレクトリに .kube ディレクトリがまだ存在しない場合は、このコマンドによって作成されます。.kube ディレクトリに config というファイルがまだ存在しない場合、これも作成されます。このファイルは、認証情報と構成情報を格納するために使用されます。構成ファイルは通常、kubeconfig ファイルと呼ばれます。

2. nano テキスト エディタで kubeconfig ファイルを開きます。

nano ~/.kube/config

これで、ファイルに保存されているすべての認証データとエンドポイント構成データを確認できるようになり、クラスタの情報が表示されます。これらの情報はクラスタの作成時に入力されたものです。

3. Ctrl+X キーを押して nano エディタを終了します。

注: kubeconfig ファイルには、多くのクラスタの情報を保存できます。現在アクティブなコンテキスト（kubectl コマンドが操作しているクラスタ）は、current-context プロパティで示されます。

同じコンテキスト（同じ環境の同じユーザー）で作成したクラスタについては、クラスタ作成時にすでに詳細が入力されているため、gcloud container clusters get-credentials コマンドを実行して kubeconfig ファイルに情報を入力する必要はありません。

ただし、他のユーザーまたは他の環境で作成されたクラスタに接続するには、このコマンドの実行が必要です。このコマンドを使うと、アクティブなコンテキストを別のクラスタに簡単に切り替えることも可能です。

タスク 3. kubectl を使用して GKE クラスタを検査する

このタスクでは、Cloud Shell と kubectl を使用して GKE クラスタを検査します。

kubeconfig ファイルに情報が入力され、アクティブなコンテキストが特定のクラスタに設定されたら、kubectl コマンドライン ツールを使用して、対象のクラスタに対してコマンドを実行できます。こうしたコマンドの多くは、最終的にマスター API サーバーに対する REST API 呼び出しをトリガーします。これにより、関連するアクションが実行されます。

1. Cloud Shell で次のコマンドを実行して、kubeconfig ファイルの内容を出力します。

kubectl config view

証明書の機密データは DATA+OMITTED で置き換えられて表示されます。

2. Cloud Shell で次のコマンドを実行して、アクティブ コンテキストのクラスタ情報を出力します。

kubectl cluster-info

出力にアクティブ コンテキストのクラスタの情報が示されます。

出力:

Kubernetes control plane is running at https://34.133.211.75 GLBCDefaultBackend is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy KubeDNSUpstream is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/kube-dns-upstream:dns/proxy Metrics-server is running at https://34.133.211.75/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

3. Cloud Shell で次のコマンドを実行して、アクティブ コンテキストを出力します。

kubectl config current-context

出力に、アクティブ コンテキストのクラスタが 1 行で示されます。

出力:

gke_{{{project_0.project_id|Project_ID}}}_{{{project_0.default_region|Region}}}_autopilot-cluster-1

PROJECT_ID はプロジェクト ID です。この情報は、kubeconfig ファイルの current-context プロパティの情報と同じです。

4. Cloud Shell で次のコマンドを実行して、kubeconfig ファイル内のすべてのクラスタ コンテキストの詳細を出力します。

kubectl config get-contexts

出力には、作成したクラスタに関する詳細と、どれがアクティブ コンテキスト クラスタであるかを示す内容が数行で表示されます。通常、ユーザーの kubeconfig ファイルに存在するクラスタの詳細（ユーザーが作成した他のクラスタや、kubeconfig ファイルに手動で追加したクラスタの詳細を含む）が示されます。

5. Cloud Shell で次のコマンドを実行して、アクティブ コンテキストを変更します。

kubectl config use-context gke_${DEVSHELL_PROJECT_ID}_{{{project_0.default_region|Region}}}_autopilot-cluster-1

この例ではクラスタは 1 つのみであるため、このコマンドを実行しても何も変更されません。

しかし、将来的にはプロジェクトのクラスタが複数になる可能性があります。複数のクラスタの認証情報と構成情報が kubeconfig ファイルにすでに入力されている場合、この方法でアクティブ コンテキストを切り替えることができます。この方法では、クラスタの完全な名前（gke 接頭辞、プロジェクト ID、ロケーション、表示名をアンダースコアで連結したもの）を指定する必要があります。

6. Cloud Shell で次のコマンドを実行して、kubectl の bash のオートコンプリートを有効にします。

source <(kubectl completion bash)

このコマンドは出力を生成しません。

7. Cloud Shell で「kubectl」と入力し、その後にスペースを 1 つ入力してから、Tab キーを 2 回押します。

使用可能なコマンドがすべて出力されます。

8. Cloud Shell に「kubectl co」と入力して、Tab キーを 2 回押します。

「co」で始まるすべてのコマンドが出力されます。他のテキストを入力した場合も同様になります。

タスク 4. GKE クラスタに Pod をデプロイする

このタスクでは、Cloud Shell を使用して GKE クラスタに Pod をデプロイします。

kubectl を使用して GKE に Pod をデプロイする

Kubernetes は Pod を抽象化することで 1 つ以上の関連コンテナを単一のエンティティとしてグループ化し、これらを 1 つのユニットとして同一ノード上でスケジュールしてデプロイします。1 つのコンテナ イメージから作成された 1 つのコンテナを含む Pod をデプロイすることも、複数のコンテナ イメージから作成された複数のコンテナを Pod に含めることも可能です。

1. Cloud Shell で次のコマンドを実行して、nginx を nginx-1 という名前の Pod としてデプロイします。

kubectl create deployment --image nginx nginx-1

このコマンドでは、nginx イメージを実行するコンテナを含む、nginx という Pod が作成されます。リポジトリが指定されていない場合、デフォルトの動作として、ローカルまたは Docker 一般公開リポジトリにあるイメージが検索されます。この例では、イメージは Docker 一般公開レジストリから pull されます。

2. Cloud Shell で次のコマンドを実行して、アクティブなコンテキストのクラスタにデプロイされたすべての Pod を表示します。

kubectl get pods

出力は次の例のようになりますが、実際の Pod 名は多少異なります。

注: サーバーが現在リクエストを処理できないというメッセージが表示された場合は、デプロイが完了して準備ができるまで待機します。

出力:

NAME READY STATUS RESTARTS AGE nginx-1-74c7bbdb84-nvwsc 1/1 Running 0 2m52s

3. Cloud Shell で次のコマンドを実行して、クラスタのすべてのノードのリソース使用状況を表示します。

kubectl top nodes

出力は次の例のようになります。

出力:

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gk3-autopilot-cluster-1-pool-2-7246ae0e-4q7s 1971m 102% 1803Mi 30%

別の top コマンド（kubectl top pods）を実行すると、クラスタにデプロイされたすべての Pod に関する同様の情報を表示できます。

4. ここで、このラボ全体で使用する変数に Pod 名を入力します。このような変数を使用することで、長い名前を入力する際のミスを最小限に抑えることができます。[your_pod_name] の代わりに、一意の Pod 名を入力してください。

export my_nginx_pod=[your_pod_name]

例:

export my_nginx_pod=nginx-1-74c7bbdb84-nvwsc

5. シェルに値をエコーバックさせて、環境変数が適切に設定されたことを確認します。

echo $my_nginx_pod

出力:

nginx-1-74c7bbdb84-nvwsc

6. Cloud Shell で次のコマンドを実行して、作成した Pod の詳細をすべて表示します。

kubectl describe pod $my_nginx_pod

出力は次の例のようになります。Pod の詳細、ステータス、状態、ライフサイクルのイベントが表示されます。

出力:

Image: nginx Image: nginx Image: nginx Image ID: docker.io/library/nginx@sha256:480868e8c8c797794257e2abd88d0f9a8809b2fe956cbfbc05dcc0bca1f7cd43 Port: Host Port: State: Running Started: Wed, 17 May 2023 10:47:04 +0000 Ready: True Restart Count: 0 Limits: cpu: 500m ephemeral-storage: 1Gi memory: 2Gi Requests: cpu: 500m ephemeral-storage: 1Gi memory: 2Gi Environment: Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ksxxr (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-ksxxr: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: DownwardAPI: true QoS Class: Guaranteed Node-Selectors: Tolerations: kubernetes.io/arch=amd64:NoSchedule node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 5m42s gke.io/optimize-utilization-scheduler 0/2 nodes are available: 2 Insufficient cpu, 2 Insufficient memory. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod. Normal Scheduled 4m15s gke.io/optimize-utilization-scheduler Successfully assigned default/nginx-1-6b7bff9fc7-t7fzk to gk3-autopilot-cluster-1-pool-1-242a3a6a-j9rh Normal TriggeredScaleUp 5m34s cluster-autoscaler pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-02-92c260add90a/zones/{{{project_0.default_zone|Zone}}}/instanceGroups/gk3-autopilot-cluster-1-pool-1-242a3a6a-grp 0->1 (max: 1000)}] Normal Pulling 3m30s kubelet Pulling image "nginx" Normal Pulled 3m16s kubelet Successfully pulled image "nginx" in 13.843394735s (13.843643782s including waiting) Normal Created 3m16s kubelet Created container nginx Normal Started 3m15s kubelet Started container nginx

コンテナにファイルを push する

nginx ウェブサーバーを介した静的コンテンツの配信を可能にするには、ファイルを作成してコンテナに配置する必要があります。

1. Cloud Shell に次のコマンドを入力し、nano テキスト エディタで test.html というファイルを開きます。

nano ~/test.html

2. 空の test.html ファイルに次のテキスト（シェル スクリプト）を追加します。

This is title Hello World

3. Ctrl+X キーを押した後、Y キーと Enter キーを押してファイルを保存し、nano エディタを終了します。

4. Cloud Shell で次のコマンドを実行し、nginx Pod の nginx コンテナ内の適切な場所にファイルを配置します。これにより、ファイルが静的に配信されます。

kubectl cp ~/test.html $my_nginx_pod:/usr/share/nginx/html/test.html

このコマンドを実行すると、test.html ファイルがローカルのホーム ディレクトリから、nginx Pod 内の最初のコンテナの /usr/share/nginx/html ディレクトリにコピーされます。-c オプションに続けてコンテナの名前を入力すると、マルチコンテナの Pod の他のコンテナを指定できます。

テスト用に Pod を公開する

Pod をクラスタの外部のクライアントに公開するには、Service が必要です。Service についてはこのコースで別途説明していますが、他のラボでも広く使用されています。シンプルなコマンドを使用して、Pod を公開する Service を作成できます。

1. Cloud Shell で次のコマンドを実行し、nginx Pod を外部に公開する Service を作成します。

kubectl expose pod $my_nginx_pod --port 80 --type LoadBalancer

このコマンドを実行すると、クラスタ外のインターネット アドレスから nginx Pod へのアクセスを許可する LoadBalancer Service が作成されます。

2. Cloud Shell で次のコマンドを実行し、クラスタ内の Service についての詳細を表示します。

kubectl get services

出力は次の例のようになります。外部 IP アドレスは次の手順で使用します。

注: 新しい Service に外部 IP アドレスが割り当てられるまで、コマンドを数回繰り返さなければならない場合があります。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.11.240.1 443/TCP 1h nginx-1-7...wsc LoadBalancer 10.11.240.87 80:31695/TCP 3s

Kubernetes Service は、クラスタによって作成または使用されるデフォルト Service の一つです。先ほど作成した nginx Service も表示されます。

外部 IP アドレスが表示されない場合は、このコマンドを何度か実行してみてください。

出力:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.11.240.1 443/TCP 1h nginx-1-7...wsc LoadBalancer 10.11.240.87 104.154.177.46 80:31695/TCP 1m

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 GKE クラスタに Pod をデプロイする

3. Cloud Shell で次のコマンドを実行し、コピーした静的 HTML ファイルが nginx コンテナで配信されていることを確認します。

[EXTERNAL_IP] は、前の手順の出力から取得した Service の外部 IP アドレスに置き換えてください。

curl http://[EXTERNAL_IP]/test.html

出力にファイルの内容が表示されます。ブラウザで同じアドレスにアクセスすると、ファイルが HTML としてレンダリングされることを確認できます。

例:

curl http://104.154.177.46/test.html This is title Hello World

4. Cloud Shell で次のコマンドを実行し、nginx Pod で使用されているリソースを表示します。

kubectl top pods

出力:

NAME CPU(cores) MEMORY(bytes) nginx-1-74c7bbdb84-nvwsc 0m 2Mi

タスク 5. GKE Pod をイントロスペクトする

このタスクでは、Pod に接続して設定の調整とファイルの編集を行います。また、Pod に対するその他の変更をライブで行います。

注: トラブルシューティングまたはテストをする場合のみ、この処理を行ってください。行った変更は Pod のソースイメージには適用されないため、いずれのレプリカにも反映されません。

環境を準備する

Pod や他のリソースを Kubernetes にデプロイするには、構成ファイルを使うことをおすすめします。構成ファイルはマニフェスト ファイルとも呼ばれます。構成ファイルは通常 YAML 構文で記述され、リソースの詳細を指定します。構成ファイルでは、長々としたコマンドライン引数を使用するよりも簡単に、複雑なオプションを指定できます。

YAML 構文は JSON 構文と似ていながらもより簡潔で、オブジェクトとプロパティを JSON 構文と同じように階層構造化できます。ラボのソース リポジトリには、サンプル YAML ファイルがあらかじめ用意されています。

1. Cloud Shell に次のコマンドを入力して、ラボの Cloud Shell にリポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

2. 作業ディレクトリへのショートカットとしてソフトリンクを作成します。

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

3. このラボのサンプル ファイルが含まれているディレクトリに移動します。

cd ~/ak8s/GKE_Shell/

new-nginx-pod.yaml という Pod のサンプル YAML マニフェスト ファイルがあらかじめ用意されています。

apiVersion: v1 kind: Pod metadata: name: new-nginx labels: name: new-nginx spec: containers: - name: new-nginx image: nginx ports: - containerPort: 80

4. 次のコマンドを実行して、マニフェストをデプロイします。

kubectl apply -f ./new-nginx-pod.yaml

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 YAML ファイルを使用して新しい Pod をデプロイする

5. 次のコマンドを実行して、Pod のリストを表示します。

kubectl get pods

出力は次のようになります。

出力:

NAME READY STATUS RESTARTS AGE new-nginx 1/1 Running 0 9s nginx-1-74c7bbdb84-nvwsc 1/1 Running 0 55m

新しい nginx Pod と、ラボですでに作成した Pod が表示されます。

シェル リダイレクトを使用して Pod に接続する

一部のコンテナ イメージにはシェル環境が含まれており、これを起動することができます。場合によっては、こうしたシェル環境を使用するほうが kubectl で個別のコマンドを実行するよりも便利です。たとえば、nginx イメージには bash シェルが含まれています。このタスクでは、シェル リダイレクトを使用して新しい nginx Pod の bash シェルに接続し、一連のアクションを実行します。

1. Cloud Shell で次のコマンドを実行して、nginx コンテナでインタラクティブな bash シェルを起動します。

kubectl exec -it new-nginx -- /bin/bash

新しいシェル プロンプトが表示されます。

出力:

root@new-nginx:/#

new-nginx Pod のコンテナで、インタラクティブな bash シェルを起動しました。Pod にコンテナが複数ある場合は、-c オプションを使用して 1 つのコンテナを名前で指定できます。

nginx コンテナ イメージにはデフォルトでテキスト編集ツールが含まれていないため、インストールする必要があります。

2. Cloud Shell の nginx bash シェルで次のコマンドを実行して、nano テキスト エディタをインストールします。

apt-get update apt-get install nano

「Do you want to continue (Y/n)」というメッセージが表示されたら、Y を押して確定します。

nginx コンテナ上で静的に提供されているディレクトリに、test.html ファイルを作成する必要があります。

3. Cloud Shell の nginx bash シェルで次のコマンドを実行し、静的ファイル ディレクトリに切り替えて test.html ファイルを作成します。

cd /usr/share/nginx/html nano test.html

4. Cloud Shell で、nginx bash シェルの nano セッションに次のテキストを入力します。

This is title Hello World

5. Ctrl+X キーを押した後、Y キーと Enter キーを押してファイルを保存し、nano エディタを終了します。
6. Cloud Shell の nginx bash シェルで次のコマンドを実行して、nginx bash シェルを終了します。

exit

変更された nginx コンテナに（新しい静的 HTML ファイルを使用して）接続し、テストを行うには、Service を作成する方法もありますが、ポート転送を使用して Cloud Shell から Pod に直接接続する方が簡単です。

7. Cloud Shell で次のコマンドを実行して、Cloud Shell から nginx Pod へのポート転送（Cloud Shell VM のポート 10081 から nginx コンテナのポート 80 に転送）を設定します。

kubectl port-forward new-nginx 10081:80

出力は次のようになります。

出力:

Forwarding from 127.0.0.1:10081 -> 80 Forwarding from [::1]:10081 -> 80

これはフォアグラウンド プロセスなので、テスト用に別の Cloud Shell インスタンスを開く必要があります。

8. Cloud Shell のメニューバーでプラス記号（+）のアイコンをクリックして、新しい Cloud Shell セッションを開始します。

2 つ目の Cloud Shell セッションが Cloud Shell ウィンドウに表示されます。メニューバーのタイトルをクリックすると、セッションを切り替えることができます。

9. 2 番目の Cloud Shell セッションで次のコマンドを実行して、ポート転送を介して変更された nginx コンテナをテストします。

curl http://127.0.0.1:10081/test.html

test.html ファイルに配置した HTML テキストが表示されます。

This is title Hello World

Pod のログを表示する

1. Cloud Shell のメニューバーでプラス記号（+）のアイコンをクリックして、別の新しい Cloud Shell セッションを開始します。

3 番目の Cloud Shell セッションが Cloud Shell ウィンドウに表示されます。ここでも、メニューバーでタイトルをクリックするとセッションを切り替えることができます。

2. この 3 番目の Cloud Shell ウィンドウで次のコマンドを実行して、ログを表示するとともに、新しく到着した new-nginx Pod のログをストリーミングします（タイムスタンプも追加します）。

kubectl logs new-nginx -f --timestamps

3. この新しいウィンドウにログ画面が表示されます。
4. 2 番目の Cloud Shell ウィンドウに戻り、curl コマンドを再実行して Pod にトラフィックを生成します。
5. 3 番目の Cloud Shell ウィンドウに追加のログメッセージが表示されたら、それを確認します。

6. 3 番目の Cloud Shell ウィンドウを閉じて、ログメッセージの表示を停止します。
7. 元の Cloud Shell ウィンドウを閉じて、ポート転送プロセスを停止します。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。