バージョン 1.9

オンプレミスへの Anthos Service Mesh のインストール

このガイドでは、Anthos clusters on VMware に Anthos Service Mesh バージョン 1.9.1-asm.1 をクリーン インストールする方法を説明します。以前のバージョンの Anthos Service Mesh がインストールされている場合は、Anthos Service Mesh Anthos clusters on VMware のアップグレードをご覧ください。このインストールにより、クラスタでサポートされる機能が有効になります。このガイドではクラスタを cluster1 と表記していますが、この手順を繰り返して多数のクラスタを設定することもできます。

コントロール プレーン コンポーネントの概要

Anthos clusters on VMware には、次の Istio コンポーネントがプリインストールされています。

  • Anthos Service Mesh 認証局(Citadel)は、kube-system 名前空間にインストールされます。
  • パイロットと Istio Ingress Gateway は gke-system 名前空間にインストールされます。

Anthos clusters on VMware では、これらのコンポーネントを使用して Ingress を有効にし、Google が管理するコンポーネント間のセキュア通信を実現しています。Ingress 機能のみが必要な場合は、OSS Istio または Anthos Service Mesh をインストールする必要はありません。Ingress の構成の詳細については、Ingress を有効にするをご覧ください。

Anthos Service Mesh をインストールすると、そのコンポーネントは istio-system 名前空間にインストールされます。Anthos Service Mesh コンポーネントは別の名前空間にあるため、Istio コンポーネントがプリインストールされた Anthos clusters on VMware と競合しません。

始める前に

次の要件を確認してから設定を開始してください。

要件

  • Anthos のサブスクリプションが必要です。ただし、Anthos on Google Cloud の場合のみ、従量課金制の請求オプションを使用できます。詳細については、Anthos 料金ガイドをご覧ください。

  • Anthos Service Mesh をインストールするユーザー クラスタには、少なくとも vCPU が 4 つ、メモリが 15 GB、レプリカが 4 つあることを確認します。

  • サービスポートには、name: protocol[-suffix] の構文を使用して名前を指定する必要があります。角かっこはオプションの接尾辞を示しており、この接尾辞は先頭をダッシュにする必要があります。詳細については、サービスポートの命名をご覧ください。

  • クラスタ バージョンがサポートされる環境に含まれていることを確認します。クラスタのバージョンを確認するには、gkectl コマンドライン ツールを使用します。gkectl がインストールされていない場合は、GKE On-Prem のダウンロードをご覧ください。

    gkectl version

環境設定

インストール プロセスを管理するコンピュータには、次のツールが必要です。Anthos Service Mesh はユーザー クラスタにのみインストールできます。管理クラスタにはインストールできません。

  • curl コマンドライン ツール
  • Cloud SDKgcloud コマンドライン ツール)

Cloud SDK をインストールしたら、次の手順を実施します。

  1. Cloud SDK で認証します。

    gcloud auth login
    
  2. コンポーネントを更新します。

    gcloud components update
    
  3. kubectl をインストールします。

    gcloud components install kubectl
    
  4. Online Boutique のサンプル アプリケーションでインストールをデプロイしてテストする場合は、kpt をインストールします。

    gcloud components install kpt
    

環境変数の設定

  1. このコマンドの出力の NAME 列にある値を使用して、クラスタのコンテキスト名を取得します。

    kubectl config get-contexts
  2. 環境変数をクラスタ コンテキスト名に設定します。これは、このガイドの多くの手順で使用されます。

    export CTX_CLUSTER1=CLUSTER1_CONTEXT_NAME

クラスタ管理者権限の付与

  1. ユーザー アカウント(Google Cloud ログイン メールアドレス)にクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御(RBAC)ルールを作成するのに必要です。

    kubectl --context="${CTX_CLUSTER1}" create clusterrolebinding cluster-admin-binding \
      --clusterrole=cluster-admin \
      --user=USER_ACCOUNT

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

Linux

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

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.1-asm.1-linux-amd64.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

     tar xzf istio-1.9.1-asm.1-linux-amd64.tar.gz

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

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

    cd istio-1.9.1-asm.1
  5. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

    export PATH=$PWD/bin:$PATH

Mac OS

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

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.1-asm.1-osx.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

    tar xzf istio-1.9.1-asm.1-osx.tar.gz

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

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

    cd istio-1.9.1-asm.1
  5. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

    export PATH=$PWD/bin:$PATH

Windows

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

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.1-asm.1-win.zip
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

    tar xzf istio-1.9.1-asm.1-win.zip

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

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

    cd istio-1.9.1-asm.1
  5. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

    export PATH=$PWD/bin:$PATH

認証局の構成

このセクションでは、Anthos Service Mesh オンプレミスがワークロードの署名に使用する証明書と鍵を生成する方法について説明します。

最高レベルのセキュリティを確保するには、オフラインのルート CA を維持し、下位 CA を使用して各クラスタの CA を発行することを強くおすすめします。詳しくは、CA 証明書のプラグインをご覧ください。この構成では、サービス メッシュ内のすべてのワークロードは同じルート認証局(CA)を使用します。各 Anthos Service Mesh CA は、ルート CA によって署名された中間 CA 署名鍵と証明書を使用します。メッシュ内に複数の CA が存在する場合、CA 間の信頼の階層を確立します。この手順を繰り返して、任意の数の認証局の証明書と鍵をプロビジョニングできます。

  1. 証明書と鍵のディレクトリを作成します。

    mkdir -p certs && \
    pushd certs
  2. ルート証明書と鍵を生成します。

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca
    

    これにより、次のファイルが生成されます。

    • root-cert.pem: ルート証明書
    • root-key.pem: ルート鍵
    • root-ca.conf: ルート証明書を生成するための openssl の構成
    • root-cert.csr: ルート証明書の CSR
  3. 中間証明書と鍵を生成します。

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    これにより、cluster1 という名前のディレクトリにファイルが生成されます。

    • ca-cert.pem: 中間証明書
    • ca-key.pem: 中間鍵
    • cert-chain.pem: istiod が使用する証明書チェーン
    • root-cert.pem: ルート証明書

    オフラインのコンピュータを使用してこれらの手順を実行する場合は、生成されたディレクトリを、クラスタにアクセスできるコンピュータにコピーします。

  4. すべての入力ファイル ca-cert.pemca- key.pemroot-cert.pemcert-chain.pem を含むシークレット cacerts を作成します。

    kubectl --context="${CTX_CLUSTER1}" create namespace istio-system
    kubectl --context="${CTX_CLUSTER1}" create secret generic cacerts -n istio-system \
      --from-file=cluster1/ca-cert.pem \
      --from-file=cluster1/ca-key.pem \
      --from-file=cluster1/root-cert.pem \
      --from-file=cluster1/cert-chain.pem

    Anthos Service Mesh オンプレミスは、これらの証明書/鍵の存在を検出し、後のインストール プロセスで使用します。

  5. 前のディレクトリに戻ります。

    popd

Anthos Service Mesh のインストール

  1. プロジェクト ID の環境変数を作成します。

    export PROJECT_ID=YOUR_PROJECT_ID
  2. プロジェクト番号の環境変数を作成します。

    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
  3. メッシュ ID の環境変数を作成します。任意の文字列を使用できますが、クラスタ間で一貫した形式にする必要があります。

    export MESH_ID="proj-${PROJECT_NUMBER}"
  4. クラスタのコントロール プレーンの構成を作成します。これにより、asm-multicloud プロファイルを使用して Anthos Service Mesh がインストールされます。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

    次の例では、前の手順で定義した MESH_ID を使用します。

    cat <<EOF > cluster.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      profile: asm-multicloud
      revision: asm-191-1
      values:
        global:
          meshID: MESH_ID
          multiCluster:
            clusterName: CLUSTER_NAME
          network: NETWORK_ID
    EOF
    
  5. 構成をクラスタに適用します。

    istioctl install --context="${CTX_CLUSTER1}" -f cluster.yaml
    

デフォルト ネットワークの設定

istio-system 名前空間でデフォルト ネットワークを設定します。

次の例の NETWORK_ID は、クラスタのネットワークを識別する任意の文字列にできます。このオンプレミス構成では、すべてのクラスタが独自のネットワーク上に存在するため、各クラスタに異なる値を指定する必要があります。NETWORK_ID には、構文と文字セットで説明される Kubernetes ラベルと同じ文字列制限があります。

 kubectl --context="${CTX_CLUSTER1}" label \
 namespace istio-system topology.istio.io/network=NETWORK_ID

検証 Webhook の構成

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

  1. 次の YAML を istiod-service.yaml という名前のファイルにコピーします。

    cat <<EOF > istiod-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
     name: istiod
     namespace: istio-system
     labels:
       istio.io/rev: asm-191-1
       app: istiod
       istio: pilot
       release: istio
    spec:
     ports:
       - port: 15010
         name: grpc-xds # plaintext
         protocol: TCP
       - port: 15012
         name: https-dns # mTLS with k8s-signed cert
         protocol: TCP
       - port: 443
         name: https-webhook # validation and injection
         targetPort: 15017
         protocol: TCP
       - port: 15014
         name: http-monitoring # prometheus stats
         protocol: TCP
     selector:
       app: istiod
       istio.io/rev: asm-191-1
    EOF
    
  2. 検証 Webhook を構成して、リビジョン ラベルで istiod サービスを検出できるようにします。

    kubectl --context="${CTX_CLUSTER1}" apply -f istiod-service.yaml
    

    このコマンドは、構成の適用前に検証 Webhook が構成を自動的にチェックするサービス エントリを作成します。

自動相互 TLS(自動 mTLS)はデフォルトで有効になっています。自動 mTLS の場合、クライアント サイドカー プロキシがサーバーにサイドカーがあるかどうかを自動的に検出します。クライアント サイドカーは、サイドカーを含むワークロードに mTLS を送信し、サイドカーなしでワークロードに書式なしテキストのトラフィックを送信します。

コントロール プレーン コンポーネントの確認

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

kubectl --context="${CTX_CLUSTER1}" get pod -n istio-system

予想される出力は次のようになります。

NAME                                      READY   STATUS      RESTARTS   AGE
istio-ingressgateway-74cc894bfd-786rg     1/1     Running     0          7m19s
istiod-78cdbbbdb-d7tps                    1/1     Running     0          7m36s
promsd-576b8db4d6-lqf64                   2/2     Running     1          7m19s

サイドカー プロキシの挿入

Anthos Service Mesh は、サイドカー プロキシを使用してネットワークのセキュリティ、信頼性、オブザーバビリティを強化します。Anthos Service Mesh では、これらの機能がアプリケーションのプライマリ コンテナから抽出され、同じ Pod 内の個別のコンテナとして提供される共通のプロセス外プロキシに実装されます。

インストールは、自動サイドカー プロキシ挿入(自動挿入)を有効化して、Anthos Service Mesh をインストールする前にクラスタで実行していたワークロードの Pod を再起動するまで完了しません。

自動挿入を有効にするには、Anthos Service Mesh をインストールしたときに istiod に設定したリビジョン ラベルで名前空間にラベルを付けます。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

新しいワークロードを新しい名前空間にデプロイする前に、Anthos Service Mesh がトラフィックのモニタリングと保護を行えるように自動挿入を構成してください。

自動インジェクションを有効にするには:

  1. kubectl の現在のコンテキストを設定します。

    gcloud container clusters get-credentials CLUSTER_NAME \
        --project=PROJECT_ID
    
  2. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

    kubectl -n istio-system get pods -l app=istiod --show-labels
    

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

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-191-1-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-191-1,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-191-1-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-191-1,istio=istiod,pod-template-hash=5788d57586

    出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョン ラベルの値をメモします。この例での値は asm-191-1 です。

  3. リビジョン ラベルを適用し、存在する場合は istio-injection ラベルを削除します。次のコマンドで、NAMESPACE は自動インジェクションを有効にする名前空間の名前で、REVISION は前の手順でメモしたリビジョン ラベルです。

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

    出力中のメッセージ "istio-injection not found" は無視します。つまり、今までは名前空間に istio-injection ラベルが付いていなかったということです。Anthos Service Mesh の新規インストールや新規デプロイでは、これが予想されます。名前空間に istio-injection とリビジョン ラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。

  4. Anthos Service Mesh をインストールする前にクラスタでワークロードが実行されていた場合は、Pod を再起動して再インジェクションをトリガーします。

    Pod を再起動する方法は、アプリケーションとクラスタが属する環境によって異なります。たとえば、ステージング環境では、すべての Pod を削除するのみの場合がありますが、それによって Pod が再起動されます。ただし、本番環境では、Blue/Green デプロイを実装するプロセスにより、トラフィックが中断しないように Pod を安全に再起動できます。

    kubectl を使用すると、ローリングの再起動を実行できます。

    kubectl rollout restart deployment -n NAMESPACE
    
  5. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
    

次のステップ

オンプレミス サービス メッシュに複数のクラスタを使用する場合は、複数のクラスタとネットワークへの Anthos Service Mesh オンプレミスのインストールをご覧ください。

それ以外の場合、次のステップでは外部 IP アドレスの構成を行います。