Istio から Anthos Service Mesh への移行

このページは、異なる Google Cloud プロジェクトにある複数のクラスタを含むメッシュのために、GKE クラスタで Istio から Anthos Service Mesh バージョン 1.7.8 に移行する方法を説明するガイドの一部です。単一クラスタ メッシュでの移行または同じ Google Cloud プロジェクト内の複数のクラスタを含むメッシュの場合は、GKE のインストール、移行、アップグレードをご覧ください。

< 前へ

始める前に

Anthos Service Mesh をインストールする前に、次のことを確認してください。

• 環境を設定し、必要なツールをインストールしている。
• プロジェクトを設定し、必要な API を有効にして権限を設定している。
• クラスタを設定し、必要なクラスタ オプションを有効にしている。
• Istio からの移行の準備を確認する。

認証情報と権限の設定

1. プロジェクトを初期化してインストールの準備をします。次のコマンドでサービス アカウントを作成し、サイドカー プロキシなどのコントロール プレーン コンポーネントがプロジェクトのデータとリソースに安全にアクセスできるようにします。

   curl --request POST \
     --header "Authorization: Bearer $(gcloud auth print-access-token)" \
     --data '' \
     "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"

   コマンドを実行すると、空の中かっこ {} が返されます。

2. クラスタとやり取りするために必要な認証情報を取得します。このコマンドは、クラスタに対して kubectl の現在のコンテキストも設定します。

   gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --project=${PROJECT_ID}
   

   注: デフォルトのゾーンやリージョンが設定されていない場合は、コマンドでリージョン（--region=REGION）やゾーン（--zone=ZONE）を指定する必要があります。

3. 現在のユーザーにクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御（RBAC）ルールを作成するのに必要です。

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

"cluster-admin-binding" already exists エラーが発生した場合は、無視して既存の cluster-admin-binding を続行しても問題ありません。

インストール ファイルのダウンロード

Linux

Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig istio-1.7.8-asm.10-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

想定される出力は Verified OK です。

ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

tar xzf istio-1.7.8-asm.10-linux-amd64.tar.gz

このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

• samples ディレクトリにあるサンプル アプリケーション
• Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
• Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Mac OS

Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.7.8-asm.10-osx.tar.gz.1.sig istio-1.7.8-asm.10-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

想定される出力は Verified OK です。

ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

tar xzf istio-1.7.8-asm.10-osx.tar.gz

このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

• samples ディレクトリにあるサンプル アプリケーション
• Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
• Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

Windows

Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip.1.sig
openssl dgst -verify - -signature istio-1.7.8-asm.10-win.zip.1.sig istio-1.7.8-asm.10-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

想定される出力は Verified OK です。

ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

tar xzf istio-1.7.8-asm.10-win.zip

このコマンドにより、現在の作業ディレクトリに istio-1.7.8-asm.10 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

• samples ディレクトリにあるサンプル アプリケーション
• Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
• Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。

1. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

   cd istio-1.7.8-asm.10

2. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

   export PATH=$PWD/bin:$PATH

リソース構成ファイルの準備

istioctl install コマンドを実行するときは、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、Anthos Service Mesh で必要なプロジェクトとクラスタに関する情報が含まれています。プロジェクトとクラスタの情報を設定できるように、istio-operator.yaml と他のリソース構成ファイルを含むパッケージをダウンロードする必要があります。

リソース構成ファイルを準備するには:

Mesh CA

1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

3. パッケージをダウンロードします。

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
   

4. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

   kpt cfg set asm gcloud.core.project ${PROJECT_ID}
   

5. フリート ホスト プロジェクトのプロジェクト番号を設定します。

   kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
   

6. クラスタ名を設定します。

   kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
   

7. デフォルトのゾーンまたはリージョンを設定します。

   kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
   

8. インストールする Anthos Service Mesh のバージョンにタグを設定します。

   kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
   

9. リビジョン ラベルを使用するように Webhook の検証を設定します。

   kpt cfg set asm anthos.servicemesh.rev asm-178-10
   

   Anthos Service Mesh をインストールするときに、istiod にリビジョン ラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。

10. マルチクラスタ構成内のクラスタは異なるプロジェクトにあるため、マルチクラスタ / マルチプロジェクトのサービスメッシュを形成する他のプロジェクトに、信頼できるドメイン エイリアスを構成する必要があります。

    1. マルチクラスタ / マルチプロジェクト メッシュに含まれるすべてのクラスタのプロジェクト ID を取得します。

    2. 各クラスタのプロジェクト ID に、信頼ドメイン エイリアスを設定します。たとえば、3 つのプロジェクトにクラスタがある場合は、次のコマンドを実行して、PROJECT_ID_1、PROJECT_ID_2、PROJECT_ID_3 を各クラスタのプロジェクト ID に置き換えます。

       kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

       他のプロジェクトにクラスタを構成する場合は、同じコマンドを使用できます。

       信頼ドメイン エイリアスにより、Mesh CA は他のプロジェクトのクラスタ上のワークロードを認証できます。Anthos Service Mesh をインストールした後、信頼ドメイン エイリアスを設定するだけでなく、クラスタ間で負荷分散を有効にする必要があります。

11. kpt セッターの値を出力します。

    kpt cfg list-setters asm
    

    コマンドの出力は、次のようになります。

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.7.8-asm.10
    anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    次のセッターの値が正しいことを確認します。

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    他のセッターの値は無視してかまいません。

Citadel

1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

3. パッケージをダウンロードします。

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
   

4. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

   kpt cfg set asm gcloud.core.project ${PROJECT_ID}
   

5. フリート ホスト プロジェクトのプロジェクト番号を設定します。

   kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
   

6. クラスタ名を設定します。

   kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
   

7. デフォルトのゾーンまたはリージョンを設定します。

   kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
   

8. インストールする Anthos Service Mesh のバージョンにタグを設定します。

   kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
   

9. リビジョン ラベルを使用するように Webhook の検証を設定します。

   kpt cfg set asm anthos.servicemesh.rev asm-178-10
   

10. kpt セッターの値を出力します。

    kpt cfg list-setters asm
    

    コマンドの出力は、次のようになります。

                              NAME                                                       VALUE
    anthos.servicemesh.canonicalServiceHub               gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10
    anthos.servicemesh.controlplane.monitoring.enabled   true
    anthos.servicemesh.hub                               gcr.io/gke-release/asm
    anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
    anthos.servicemesh.tag                               1.7.8-asm.10
    anthos.servicemesh.trustDomainAliases
    base-dir                                             base
    gcloud.compute.location                              us-central
    gcloud.compute.network                               default
    gcloud.compute.subnetwork                            default
    gcloud.container.cluster                             example-cluster-1
    gcloud.container.cluster.clusterSecondaryRange
    gcloud.container.cluster.releaseChannel              REGULAR
    gcloud.container.cluster.servicesSecondaryRange
    gcloud.container.nodepool.max-nodes                  4
    gcloud.core.project                                  example-project-12345
    gcloud.project.environProjectID                      FLEET_PROJECT_ID
    gcloud.project.environProjectNumber                  1234567890123
    gcloud.project.projectNumber                         9876543210987

    次のセッターの値が正しいことを確認します。

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    他のセッターの値は無視してかまいません。

Anthos Service Mesh への移行

Istio から移行するには、デュアル コントロール プレーンのアップグレード プロセス（Istio ドキュメントではカナリア アップグレードと呼ばれます）に従います。デュアル コントロール プレーンのアップグレードでは、既存のコントロール プレーンを残しながら、新しいバージョンのコントロール プレーンをインストールします。新しいバージョンをインストールする際は、新しいコントロール プレーンのバージョンを識別する revision ラベルを含めます。各リビジョンは、独自の Deployment と Service を持つ完全な Anthos Service Mesh コントロール プレーンの実装です。

新しいコントロール プレーンを参照するようにワークロードに同じ revision ラベルを設定し、ローリング再起動を行い、新しい Anthos Service Mesh バージョンでプロキシを再挿入して新しいバージョンに移行します。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。これは、インプレース アップグレードを行うよりもはるかに安全です。インプレース アップグレードでは、以前のバージョンのコントロール プレーンが新しいコントロール プレーンで瞬時に置き換わります。

コントロール プレーンの更新

Mesh CA

1. 現在の kubeconfig コンテキストが、Anthos Service Mesh をインストールするクラスタを指していることを確認します。

   kubectl config current-context
   

   出力は次の形式になります。

   gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

   kubeconfig コンテキストと kpt セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。

2. 次のコマンドを実行し、asm-gcp-multiproject プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

   重要: GKE 1.15 にインストールする場合は、次のコマンドで指定するオーバーレイ ファイルに加えて、オーバーレイ ファイル -f asm/istio/options/v1beta1-crds.yaml を追加する必要があります。

   istioctl install \
     -f asm/istio/istio-operator.yaml \
     -f asm/istio/options/multiproject.yaml \
     -f asm/istio/options/multicluster.yaml\
     --revision=asm-178-10
   

   --revision 引数は、istio.io/rev=asm-178-10 形式のリビジョン ラベルを istiod に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

   次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。

   • multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。

   • multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

3. istio-system のコントロール プレーン Pod が稼働していることを確認します。

   kubectl get pods -n istio-system
   

   出力例:

   NAME                                        READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
   istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
   istiod-asm-178-10-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
   istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

   コントロール プレーンの 2 つの Deployment と Service が並行して実行されている。

4. 正規サービス コントローラをクラスタにデプロイします。

   kubectl apply -f asm/canonical-service/controller.yaml

   正規サービス コントローラは、同じ論理サービスに属するワークロードをグループ化します。正規サービスのさらに詳しい内容については、正規サービスの概要をご覧ください。

Citadel

1. 現在の kubeconfig コンテキストが、Anthos Service Mesh をインストールするクラスタを指していることを確認します。

   kubectl config current-context
   

   出力は次の形式になります。

   gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

   kubeconfig コンテキストと kpt セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。

2. 次のコマンドを実行し、asm-gcp-multiproject プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

   重要: GKE 1.15 にインストールする場合は、次のコマンドで指定するオーバーレイ ファイルに加えて、オーバーレイ ファイル -f asm/istio/options/v1beta1-crds.yaml を追加する必要があります。

   istioctl install \
     -f asm/istio/istio-operator.yaml \
     -f asm/istio/options/citadel-ca.yaml \
     -f asm/istio/options/multiproject.yaml \
     -f asm/istio/options/multicluster.yaml\
     --revision=asm-178-10
   

   --revision 引数は、istio.io/rev=asm-178-10 形式のリビジョン ラベルを istiod に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

   次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。

   • citadel-ca.yaml によって、Citadel が CA として構成されます。

   • multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。

   • multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

3. istio-system のコントロール プレーン Pod が稼働していることを確認します。

   kubectl get pods -n istio-system
   

   出力例:

   NAME                                        READY   STATUS    RESTARTS   AGE
   istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
   istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
   istiod-asm-178-10-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
   istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

   コントロール プレーンの 2 つの Deployment と Service が並行して実行されている。

4. 正規サービス コントローラをクラスタにデプロイします。

   kubectl apply -f asm/canonical-service/controller.yaml

   正規サービス コントローラは、同じ論理サービスに属するワークロードをグループ化します。正規サービスのさらに詳しい内容については、正規サービスの概要をご覧ください。

ワークロードの再デプロイ

新しいリビジョンをインストールしても、既存のサイドカー プロキシには影響しません。これらをアップグレードするには、新しいコントロール プレーンを指すように構成する必要があります。これは、名前空間ラベル istio.io/rev に基づいたサイドカー インジェクションで制御されます。

1. 新しい Anthos Service Mesh バージョンで挿入されるワークロードを更新します。

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-178-10 --overwrite

   istio.io/rev ラベルよりも優先されるため、istio-injection ラベルは削除する必要があります。

2. Pod を再起動してインジェクションを再度トリガーします。

   kubectl rollout restart deployment -n NAMESPACE

3. Pod が istiod-asm-178-10 コントロール プレーンを参照するように構成されていることを確認します。

   kubectl get pods -n NAMESPACE -l istio.io/rev=asm-178-10
   

4. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

5. 他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。

6. アプリケーションが期待どおりに機能していることを確認したら、移行を完了するに進みます。それ以外の場合は、次の手順で以前のバージョンにロールバックします。

   ロールバックするには:

   1. コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。

      kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

   2. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE

   3. 以前のバージョンの istio-ingressgateway を再デプロイします。

      kubectl -n istio-system rollout undo deploy istio-ingressgateway
      

   4. 新しいコントロール プレーンを削除します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-178-10 -n istio-system --ignore-not-found=true
      

移行を完了する

アプリケーションが期待どおりに機能していることを確認したら、次の手順で Anthos Service Mesh への移行を完了します。

1. 古いコントロール プレーンを削除します。

   kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
   

クラスタの登録

Google Cloud コンソールで統合ユーザー インターフェースにアクセスするには、クラスタをプロジェクトのフリートに登録する必要があります。フリートは、Google Cloud 外のクラスタを含むクラスタとそのワークロードを表示して管理するために統合された方法を提供します。

クラスタの登録については、フリートへのクラスタの登録をご覧ください。

次のステップ

• Online Boutique サンプル アプリケーションをデプロイする
• Anthos Service Mesh にクラスタを追加する

< 前へ