Istio on GKE のインストール

このガイドでは、新規クラスタと既存のクラスタのインストール オプションを含む Istio on GKE アドオンの使用を開始する方法について説明します。アドオンは、gcloud コマンドライン ツールまたは Google Cloud Console を使用してインストールできます。

Istio on GKE アドオンの詳細と、お客様に適しているかどうかについては、概要をご覧ください。

始める前に

次の手順で Kubernetes Engine API を有効にします。

  1. Google Cloud Console で Kubernetes Engine ページにアクセスします。
  2. プロジェクトを作成または選択します。
  3. API と関連サービスが有効になるのを待ちます。 これには数分かかることがあります。
  4. Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

次のコマンドライン ツールがインストールされていることを確認します。

  • gcloud は、Istio on GKE アドオンを使用してクラスタを作成、更新するなど、Kubernetes Engine クラスタの作成と削除に使用されます。gcloud は Google Cloud SDK に含まれています。GCP プロジェクトで使用できるように、手順に従ってインストールおよび初期化してください。既存の gcloud がインストールされている場合は、少なくともバージョン 208.0.0 であることを確認します。
    gcloud version
    新しい Istio 対応のクラスタを作成するために gcloud をインストールする必要はありません。代わりに Google Cloud Console を使用できますが、既存のクラスタの管理や、kubectl などのツールのインストールにはやはり便利です。
  • kubectl は、GKE で使用されるクラスタ オーケストレーション システムである Kubernetes の管理に使用されます。gcloud を使用して kubectl をインストールできます。
    gcloud components install kubectl

gcloud コマンドライン ツールのデフォルトの設定

次のようにしてデフォルト値を設定しておくと、gcloud コマンドライン ツールでプロジェクト ID および Compute Engine ゾーン オプションを入力する時間が節約されます。
gcloud config set project project-id
gcloud config set compute/zone compute-zone

セキュリティ オプションの選択

Istio on GKE でクラスタを作成または更新する際には、デフォルトのメッシュ全体のセキュリティ オプションの選択肢が 2 つあります。どちらを選択するかは、最初のアプリケーションのニーズに応じて決定します。

  • Strict mTLS: このセキュリティ モードでは、宛先固有のルールでオーバーライドしない限り、Istio はデフォルトでメッシュ内のすべてのサービスとコントロール プレーン コンポーネント間の相互 TLS(mTLS)暗号化を適用します。メッシュ内のすべての通話は暗号化され、サービスは暗号化されていないトラフィックを受け入れません。
  • Permissive mTLS: このセキュリティ モードでは、Istio は、デフォルトでメッシュ内のサービスが暗号化されたトラフィックと暗号化されていないトラフィックの両方を受け入れることができ、すべてのサービスがデフォルトで暗号化されていない呼び出しを送信します。厳格な mTLS と同様に、特定のサービスでこれをオーバーライドできます。このオプションは、暗号化されていないトラフィックを受け入れるサービスが必要な場合(たとえば、サービスを Istio に完全に移行していない場合や、メッシュの外部にあるレガシー クライアントから送信されるトラフィックがある場合)に使用します。Istio on GKE は、その後セキュリティ強化のために厳格な mTLS に簡単に移行できるため、セキュリティを有効にせずにただ Istio をインストールするのではなく、このモードを提供しています。

セキュリティのデフォルト設定を更新する方法と、その他の Istio セキュリティの構成方法については、下記のセキュリティ デフォルトの更新をご覧ください。

サポートされている GKE クラスタ バージョン

Istio on GKE を使用して作成または更新したクラスタにインストールされている Istio on GKE のバージョンは、クラスタ バージョンによって異なります。Istio の最新バージョン(1.4.10-gke.5)のクラスタ バージョンで使用することをおすすめします。古いバージョンを使用している場合は、この Istio on GKE バージョンが利用可能になり次第、クラスタをアップグレードしてください。

サポートされているバージョンのリストについては、Istio on GKE のバージョンをご覧ください。

Istio on GKE のインストール

Istio on GKE は、新しいクラスタと既存のクラスタのどちらにもインストールできます。いずれの場合も、Istio コントロール プレーンがインストールされます。Istio の機能を最大限に活用するには、サービス メッシュ内の Pod に Envoy サイドカー プロキシを挿入する必要があります。

Istio on GKE でのクラスタ作成

このアドオンを使用する場合は、2 つの vCPU マシンタイプを持つ少なくとも 4 つのノードクラスタを作成することをおすすめします。デフォルトの GKE の新しいクラスタ設定で Istio 自体をデプロイできますが、サンプル アプリケーションを見つけるためのリソースが不足している可能性があります。Istio on GKE アドオンには Workload Identity との互換性がありませんのでご注意ください。

Istio on GKE を使用してクラスタを作成するには:

Console

  1. Cloud Console の [Kubernetes] ページに移動し、[クラスタを作成] を選択します。
  2. デフォルトの [標準クラスタ] ダイアログで、推奨のノード数とマシンを選択します。ただし、Istio のクラスタの最小推奨サイズに注意してください。
  3. [マスターのバージョン] プルダウンで、Istio on GKE 推奨クラスタ バージョン(推奨バージョンを使用できない場合はサポートされているバージョン)を選択します。
  4. [可用性、ネットワーキング、セキュリティ、その他の機能] を選択して、Istio on GKE などの追加の構成オプションを表示します。
  5. [Istio(ベータ版)を有効にする] を選択します。
  6. クラスタで使用する mTLS セキュリティ モードをプルダウンから選択します。
  7. [作成] をクリックしてクラスタを作成します。

コマンドライン

Istio を有効にし、デフォルトの相互 TLS で GKE クラスタを作成するには、次のコマンドを実行します。このとき、CLUSTER_NAME は選択したクラスタ名、CLUSTER_VERSION互換性のあるクラスタ バージョンに置き換えます。

gcloud beta container clusters create CLUSTER_NAME \
    --addons=Istio --istio-config=auth=MTLS_STRICT \
    --cluster-version=CLUSTER_VERSION \
    --machine-type=n1-standard-2 \
    --num-nodes=4

または、Istio を有効にし、mTLS を使用して制約なしモードで GKE クラスタを作成するには、次のようにします。

gcloud beta container clusters create CLUSTER_NAME \
    --addons=Istio --istio-config=auth=MTLS_PERMISSIVE \
    --cluster-version=CLUSTER_VERSION \
    --machine-type=n1-standard-2 \
    --num-nodes=4

Istio on GKE を既存のクラスタに追加する

アドオンでクラスタを更新する場合は、Istio のリソースが不足しないように、最初にクラスタのサイズを変更する必要があります。新しいクラスタを作成する場合と同様に、2 つの vCPU マシンタイプを備えたノードクラスタを 4 つ以上作成することをおすすめします。

アドオンを使用するには、クラスタでサポートされているクラスタ マスター バージョンが実行されている必要があります。Istio on GKE アドオンには Workload Identity との互換性がありませんのでご注意ください。

Istio on GKE アドオンを使用して既存のクラスタを更新するには:

Console

  1. Cloud Console の Kubernetes クラスタページに移動して、更新するクラスタを選択します。
  2. [編集] を選択します。
  3. [Istio(ベータ版)] で [有効] を選択して、[Istio mTLS(ベータ版)] を表示します。
  4. クラスタで使用する mTLS セキュリティ モードをプルダウンから選択します。
  5. [保存] をクリックしてクラスタを更新します。

コマンドライン

既存のクラスタにデフォルトで相互 TLS を適用した Istio を追加するには、次のコマンドを実行します。このとき、CLUSTER_NAME はクラスタ名で置き換えます。

gcloud beta container clusters update CLUSTER_NAME \
    --update-addons=Istio=ENABLED --istio-config=auth=MTLS_STRICT

制約なしモードの mTLS で既存のクラスタに Istio を追加するには、次のコマンドを実行します。

gcloud beta container clusters update CLUSTER_NAME \
    --update-addons=Istio=ENABLED --istio-config=auth=MTLS_PERMISSIVE

実際のクラスタ構成によっては、clusters update コマンドで他のパラメータが必要になる場合があります。

クラスタに既存のアプリケーションがある場合、Istio で管理されるように移行する方法についてIstio ドキュメントで説明します。

インストールの確認

Istio on GKE のインストールが成功したことを確認するには:

  1. クラスタを更新せずに作成した場合は、GKE バージョン 1.10.6 以降が起動していることを確認してください。
    gcloud container clusters list
    
    出力は次のようになります。
    NAME        LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION   NUM_NODES  STATUS
    istio-demo  us-central1-b  1.11.2-gke.15   35.239.252.38  n1-standard-2  1.11.2-gke.15  4          RUNNING
    
  2. kubectl を使用して操作できるように、新しいクラスタの認証情報を取得します。
    gcloud container clusters get-credentials CLUSTER_NAME
    
  3. Kubernetes Service の istio-citadelistio-egressgatewayistio-pilotistio-ingressgatewayistio-policyistio-sidecar-injectoristio-telemetry がデプロイされていることを確認します(デプロイされた他のサービスも表示されます)。
    kubectl get service -n istio-system
    
    NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                                                                                                   AGE
    istio-citadel              ClusterIP      10.47.245.92    <none>        8060/TCP,9093/TCP                                                                                                         12s
    istio-egressgateway        ClusterIP      10.47.248.129   <none>        80/TCP,443/TCP                                                                                                            12s
    istio-galley               ClusterIP      10.47.248.109   <none>        443/TCP,9093/TCP                                                                                                          12s
    istio-ingressgateway       LoadBalancer   10.47.248.117   <pending>     80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:30221/TCP,8060:32445/TCP,853:30663/TCP,15030:32010/TCP,15031:32633/TCP   12s
    istio-pilot                ClusterIP      10.47.251.133   <none>        15010/TCP,15011/TCP,8080/TCP,9093/TCP                                                                                     12s
    istio-policy               ClusterIP      10.47.255.244   <none>        9091/TCP,15004/TCP,9093/TCP                                                                                               12s
    istio-sidecar-injector     ClusterIP      10.47.240.36    <none>        443/TCP                                                                                                                   12s
    istio-statsd-prom-bridge   ClusterIP      10.47.247.135   <none>        9102/TCP,9125/UDP                                                                                                         12s
    istio-telemetry            ClusterIP      10.47.242.73    <none>        9091/TCP,15004/TCP,9093/TCP,42422/TCP                                                                                     12s
    promsd                     ClusterIP      10.47.241.188   <none>        9090/TCP                                                                                                                  12s
    
  4. 対応する Kubernetes Pod がデプロイされ、すべてのコンテナ(istio-pilot-*istio-policy-*istio-telemetry-*istio-egressgateway-*istio-ingressgateway-*istio-sidecar-injector-*istio-citadel-*)が稼働していることを確認します。

    kubectl get pods -n istio-system
    
    NAME                                        READY   STATUS      RESTARTS   AGE
    istio-citadel-555d845b65-xfdmj              1/1     Running     0          2d
    istio-cleanup-secrets-8x2pl                 0/1     Completed   0          2d
    istio-egressgateway-667d854c49-9q5dl        1/1     Running     0          2d
    istio-galley-6c9cd5b8bb-4j4jk               1/1     Running     0          2d
    istio-ingressgateway-6c796c5594-f972p       1/1     Running     0          2d
    istio-pilot-77f74fc6f-rpbfj                 2/2     Running     0          2d
    istio-policy-655b87fff-4wbwq                2/2     Running     0          2d
    istio-security-post-install-tm2rm           0/1     Completed   1          2d
    istio-sidecar-injector-668c9fb4db-p6lwt     1/1     Running     0          2d
    istio-statsd-prom-bridge-5b645f6f4d-6pbgf   1/1     Running     0          2d
    istio-telemetry-d9848f498-wf6kh             2/2     Running     0          2d
    promsd-6b989699d8-l7jxt                 1/1     Running     0          2d
    

サイドカー インジェクションを有効にする

Istio の機能を最大限に活用するには、アプリケーションの各サービスの Pod 内で Envoy サイドカー プロキシを実行する必要があります。Envoy プロキシは、サービスへのすべての受信トラフィックと送信トラフィックを傍受し、Istio コントロール プレーンと通信します。Envoy プロキシは、Pod の Kubernetes 構成を更新することで手動で挿入できます。また、Istio の webhook ベースの自動サイドカー挿入を使用することもできます。

デフォルトでは、サイドカーの自動インジェクションはすべての名前空間で無効になっています。自動挿入を有効にするには、次のコマンドの NAMESPACE を、アプリケーションのサービスの名前空間または default に置き換えて実行します。

kubectl label namespace NAMESPACE istio-injection=enabled

実行中の Pod は作成時に追加されるため、変更を有効にするには、実行中の Pod を再起動する必要があります。名前空間での自動挿入を無効にするには、ラベルを削除し、Pod を再起動してサイドカーを削除します。

サイドカーを手動で挿入するには、サイドカーのインストールをご覧ください。

コントロール プレーンの構成

Istio on GKE はコントロール プレーン設定のほとんどを管理しますが、本番環境で使用する場合は、ユースケースに対して適切な値を選択して指定することをおすすめします。これらは、kubectl または任意の Kubernetes ツールを使用して変更できます。これらの設定は、アドオンによってインストールがアップグレードされても変更されません

水平方向のスケーリング

メッシュのトラフィックを処理するための Istio コントロール プレーン コンポーネントのレプリカが不足しないように、次のいずれかを構成します。本番環境では、istio-policyistio-telemetryistio-pilotistio-sidecar-injector に対して少なくとも 2 つのレプリカを作成することをおすすめします。

  • Pod の水平方向の自動スケーリングは、観測された CPU 使用率に基づいたレプリカ数を自動的にスケーリングします。自動スケーリング コントロール プレーン コンポーネントのデフォルトの最大値と最小値が提供されますが、必要に応じて編集できます。たとえば、kubectl edit を使用して Istio-Telemetry のオートスケーラー設定を編集する方法を以下に示します。

    kubectl edit -n istio-system HorizontalPodAutoscalers/istio-telemetry
    
  • 自動スケーリングを使用しない場合は、水平方向のスケーリング用に各コントロール プレーン要素のレプリカ数を設定できます(Singletonの Citadel は常に例外です)。たとえば、kubectl で Pilot の 2 つのインスタンスを指定する方法を以下に示します。

    kubectl scale -n istio-system --replicas=2 deployment/istio-pilot
    

リソース リクエスト

デフォルトではリソース リクエストは設定されていませんが、本番環境での使用のために、これらを適切な値に設定することで、ノードが Pod をサポートするのに十分なリソースを確保することをおすすめします。Pod 内の各コンテナに対してリソース リクエストを設定する必要があります。そうしないと、HPA の CPU に unknown が表示され、自動スケーリングが機能しません。

各コンポーネントのリソース設定で推奨される最初のステップについては、Istio インストール オプションのガイドをご覧ください。たとえば、Mixer のリソース リクエストと制限は、[mixer オプション] で行います。

kubectl edit -n istio-system Deployments/istio-telemetry

Pod 停止予算

PodDisruptionBudgets では、特定のデプロイに使用可能なレプリカの最小数を指定できます。これにより、アプリケーションがそれに対応して動作を継続できます。

Istio on GKE のアップグレード中も使用可能なすべてのデプロイに PodDisruptionBudgets を構成する必要があります。少なくとも、独自の Ingress ゲートウェイをデプロイして外部トラフィックとして構成していない場合、アップグレード中はアプリケーションにアクセスできない場合があるため、少なくとも付属のアドオン Istio Ingress ゲートウェイ(istio-ingressgateway)に対してこの構成を行うことをおすすめします。

上記のように、Pod 停止予算の設定は水平方向のスケーリング設定とともに構成する必要があります。Istio on GKE のアップグレード プロセスでは、アップグレード中に個々のレプリカが使用できなくなるため、レプリカまたはオートスケーラーの最小レプリカの数を Pod 停止予算の最小数よりも大きくする必要があります。 これにより、アップグレード中に PodDisruptionBudgetminAvailable 設定に違反せず、アップグレードは想定どおりに機能するようになります。

インストールをカスタマイズする

Istio on GKE は多くのユースケースで妥当なデフォルト動作を提供しますが、テレメトリー ツールの構成やゲートウェイの追加など、インストール環境をさまざまな方法でカスタマイズできます。このセクションでは、サポートされるカスタマイズを行う方法について説明します。

セキュリティ デフォルトの更新

実行中のクラスタで、デフォルトの Istio mTLS セキュリティ モードを [Strict] から [Permissive] に(またはその逆に)切り替えるには、クラスタに Istio を追加するときと同じコマンドを使用します。

Console

  1. Cloud Console の Kubernetes クラスタページに移動して、更新するクラスタを選択します。
  2. [編集] を選択します。
  3. [Istio(ベータ版)] で [有効] を選択して、[Istio mTLS(ベータ版)] を表示します。
  4. クラスタで使用する mTLS セキュリティ モードをプルダウンから選択します。
  5. [保存] をクリックしてクラスタを更新します。

コマンドライン

相互 TLS で Istio をデフォルトで使用するようにクラスタを変更するには、次のコマンドを実行します。このとき、CLUSTER_NAME はクラスタ名で置き換えます。

$ gcloud beta container clusters update CLUSTER_NAME \
    --update-addons=Istio=ENABLED --istio-config=auth=MTLS_STRICT

または、クラスタを制限なしモードの mTLS に変更します。

$ gcloud beta container clusters update CLUSTER_NAME \
    --update-addons=Istio=ENABLED --istio-config=auth=MTLS_PERMISSIVE

暗号化されていないトラフィックを送受信する必要があるサービスを保持しつつ、厳格な mTLS を有効にすると、アプリケーションが機能しなくなることがあります。厳格な mTLS に移行する方法について詳しくは、相互 TLS 移行をご覧ください。より詳細な宛先固有の認証ポリシーを指定することもできます。宛先固有の認証ポリシーは、Strict から Permissive に(またはその逆に)切り替える場合でも、グローバルのデフォルトの mTLS 設定よりも優先されます。

ロールベースの承認の設定など、Istio セキュリティの構成と操作の詳細については、Istio サイトをご覧ください。

トレースとロギング

デフォルトでは、Istio on GKE にインストールされたメッシュによって、Cloud Logging と Cloud Monitoring にロギングデータと指標データが送信されます。これにより、プロジェクトとクラスタに関連する機能が有効になります。1.1.7 より前の GKE on Istio は、デフォルトでトレースデータも送信します。詳細については、Google Cloud のオペレーション スイートのサポートをご覧ください。

特にメッシュから大量のデータが収集されると、トレースとロギングの両方で追加費用が発生します。プロジェクトで Google Cloud のオペレーション スイートの API を無効にせずにこの機能を無効にする場合は、Istio on GKE の構成を次のように更新します。

Istio on GKE で Cloud Logging を無効にするには

  1. 編集用に stackdriver-log ルールを開きます。

    kubectl edit -n istio-system rule stackdriver-log
    
  2. match 条件 (context.protocol == "http" || context.protocol == "grpc") && (context.reporter.kind | "inbound" == "inbound")"false" に置き換えます。

  3. ルールを保存して閉じます。

  4. stackdriver-log-tcp ルールを開きます。

    kubectl edit -n istio-system rule stackdriver-log-tcp
    
  5. match 条件 (context.protocol == "tcp") && (context.reporter.kind | "inbound" == "inbound")"false" に置き換えます。

  6. ルールを保存して閉じます。

Istio on GKE の Google Cloud のオペレーション スイート トレースを無効にするには

Istio on GKE バージョン 1.1.3-gke.0 以前を使用している場合、または Google Cloud のオペレーション スイート トレースを手動で有効にしている場合は、次の手順で無効にできます。

  1. 編集用に stackdriver-tracing-rule ルールを開きます。

    kubectl edit -n istio-system rule stackdriver-tracing-rule
    
  2. match 条件 context.protocol == "http" || context.protocol == "grpc""false" に置き換えます。

  3. ルールを保存して閉じます。

Istio on GKE の Google Cloud のオペレーション スイート トレースを有効にするには

バージョン 1.1.7 以降を使用していて、Google Cloud のオペレーション スイート トレースを有効にする場合:

  1. Google Cloud プロジェクトで Cloud Trace API が有効になっていることを確認します。

  2. 編集用に stackdriver-tracing-rule ルールを開きます。

    kubectl edit -n istio-system rule stackdriver-tracing-rule
    
  3. match 条件 "false"context.protocol == "http" || context.protocol == "grpc" に置き換えます。

  4. ルールを保存して閉じます。

ゲートウェイの追加

Istio Ingress ゲートウェイは、Istio on GKE インストールの一部として提供されています。デフォルトの Ingress ゲートウェイは、インストールされたリソース(RBAC、Service、Deployment)をカスタマイズする必要があまりないデプロイに適しています。フィールドを Istio ゲートウェイ構成に追加できます。また、次のコントロール プレーンの設定を変更することもできます。

  • 水平方向のスケーリング
  • リソース リクエスト
  • Pod 停止予算

GKE をアップグレードすると、Istio on GKE アドオンとアドオンによってインストールされたすべてのリソース(デフォルトの Ingress ゲートウェイを含む)が自動的にアップグレードされます。デフォルトの Ingress ゲートウェイ構成では他の値は変更しないでください。変更すると、自動アップグレード中はその変更がデフォルト値に戻されます。

カスタマイズが必要な複雑なシナリオでは、新しい Ingress ゲートウェイを作成する必要があります。Ingress ゲートウェイまたは Egress ゲートウェイを追加すると、ユーザーの制御下で管理され、自動アップグレード中に変更されることはありません。

Istio Egress ゲートウェイは、バージョン 1.1 以降のデフォルトではインストールされないことに注意してください。Ingress または Egress ゲートウェイを追加するには:

  1. 現在のユーザーにクラスタ管理者の権限を付与します。

    1. ユーザー アカウントを現在のユーザーに設定します。

      gcloud auth login
    2. 現在のユーザーにクラスタ管理者の権限を付与します。

      kubectl create clusterrolebinding cluster-admin-binding \
      --clusterrole=cluster-admin \
      --user="$(gcloud config get-value core/account)"
      
  2. Istio のドキュメントの手順に沿ってゲートウェイを追加します。

外部サービスにアクセスする

Istio 対応の Pod からの送信トラフィックは、すべてサイドカー プロキシにリダイレクトされます。デフォルトでは、Istio は不明なサービスのリクエストをパススルーするようにサイドカー プロキシを構成しますが、より厳密な制御を構成できます。ただし、 ServiceEntry の作成が許可された宛先への送信リクエストを許可するには、セキュリティ上の理由から、Egress ゲートウェイを追加します。詳細については、ブログ記事Istio の Egress トラフィックのセキュリティ管理をご覧ください。

次のステップ

  • Bookinfo サンプルをインストールして確認し、Istio の機能を確認しましょう。サンプルアプリと istioctl ツールにアクセスするには、Istio リリースコマンドを実行し、コマンドを実行する OS に対応するインストール ファイルをダウンロードします。次に、手順に沿って Istio のチュートリアルのインストールで GKE をデプロイし、アプリケーションをテストします(Istio 自体をデプロイする必要はありません)。
  • Istio の詳細については、オープンソース ドキュメントをご覧ください。
  • クラスタから Istio アドオンを削除する必要がある場合は、Istio on GKE のアンインストールをご覧ください。