Kubernetes ワークロードをオンボーディングする

注: このガイドでは、Istio API を使用する Cloud Service Mesh のみをサポートし、Google Cloud APIs はサポートしていません。詳細については、Cloud Service Mesh の概要をご覧ください。

このページでは、Cloud Service Mesh で Kubernetes ワークロードをオンボーディングする方法について説明します。

Kubernetes Service をデプロイする

Cloud Service Mesh を使用するクラスタに Kubernetes サービスをデプロイするには、次の操作を行う必要があります。

• すべてのコンテナに Kubernetes Service を作成します。すべての Deployment に接続された Kubernetes Service がそれぞれ存在することになります。

• Service ポートに名前を付けます。GKE では名前のない Service ポートを定義できますが、Cloud Service Mesh ではポートのプロトコルと一致するポートの名前を指定する必要があります。

• Deployment にラベルを付けます。これにより、同じサービスの複数のバージョン間でトラフィックを分割するなど、Cloud Service Mesh のトラフィック管理機能を使用できます。

次の Deployment と Service の例は、上述の要件を示しています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

Cloud Service Mesh が有効なクラスタに Service をデプロイしたら、必ずサイドカー プロキシを挿入してください。

例: Online Boutique のサンプルをデプロイする

anthos-service-mesh-packages リポジトリの Online Boutique サンプル アプリケーションは、microservices-demo リポジトリの元のマニフェスト セットから変更されています。ベスト プラクティスに従い、各サービスは、一意のサービス アカウントを持つ個別の名前空間にデプロイします。

1. アプリケーションの名前空間を作成します。

   kubectl apply -f \
     DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces
   

   予想される出力:

   namespace/ad created
   namespace/cart created
   namespace/checkout created
   namespace/currency created
   namespace/email created
   namespace/frontend created
   namespace/loadgenerator created
   namespace/payment created
   namespace/product-catalog created
   namespace/recommendation created
   namespace/shipping created
   

2. インジェクションの名前空間を有効にします。手順は、コントロール プレーンの実装によって異なります。

   マネージド（TD）

   デフォルトのインジェクション ラベルを名前空間に適用します。

   for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
     kubectl label namespace $ns \
         istio.io/rev- istio-injection=enabled --overwrite
   done;
   

   マネージド（Istiod）

   推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。

     for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
       kubectl label namespace $ns \
           istio.io/rev- istio-injection=enabled --overwrite
     done;
   

   マネージド Istiod コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。

   1. 利用可能なリリース チャンネルを探すには、次のコマンドを実行します。

      kubectl -n istio-system get controlplanerevision
      

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

      NAME                AGE
      asm-managed-rapid   6d7h
      

      注: 上記のリストで、コントロール プレーンのリビジョンが 2 つ表示されている場合は、1 つを削除します。クラスタに複数のコントロール プレーン チャネルを配置することはできません。

      出力で、NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリース チャンネルに対応するリビジョン ラベルです。

   2. リビジョン ラベルを名前空間に適用します。

      for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
        kubectl label namespace $ns \
            istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done;
      

   クラスタ内

   推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。

     for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
       kubectl label namespace $ns \
           istio.io/rev- istio-injection=enabled --overwrite
     done;
   

   デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションがサポートされています。 次の手順を使用します。

   1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. リビジョン ラベルを名前空間に適用します。次のコマンドで、REVISION_LABEL は前の手順でメモした istiod リビジョン ラベルの値です。

      for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
        kubectl label namespace $ns \
            istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done;
      

3. サンプル アプリケーションをクラスタにデプロイします。

   1. サービス アカウントとデプロイを作成します。

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments
      

      予想される出力:

      serviceaccount/ad created
      deployment.apps/adservice created
      serviceaccount/cart created
      deployment.apps/cartservice created
      serviceaccount/checkout created
      deployment.apps/checkoutservice created
      serviceaccount/currency created
      deployment.apps/currencyservice created
      serviceaccount/email created
      deployment.apps/emailservice created
      serviceaccount/frontend created
      deployment.apps/frontend created
      serviceaccount/loadgenerator created
      deployment.apps/loadgenerator created
      serviceaccount/payment created
      deployment.apps/paymentservice created
      serviceaccount/product-catalog created
      deployment.apps/productcatalogservice created
      serviceaccount/recommendation created
      deployment.apps/recommendationservice created
      serviceaccount/shipping created
      deployment.apps/shippingservice created
      

   2. サービスを作成します。

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/kubernetes-manifests/services
      

      予想される出力:

      service/adservice created
      service/cartservice created
      service/checkoutservice created
      service/currencyservice created
      service/emailservice created
      service/frontend created
      service/frontend-external created
      service/paymentservice created
      service/productcatalogservice created
      service/recommendationservice created
      service/shippingservice created
      

   3. サービス エントリを作成します。

      kubectl apply -f \
       DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml
      

      予想される出力:

      serviceentry.networking.istio.io/allow-egress-googleapis created
      serviceentry.networking.istio.io/allow-egress-google-metadata created
      

サービスポートに名前を付ける

Cloud Service Mesh に配置するには、サービスポートに名前を付ける必要があります。名前にはポートのプロトコルが含まれている必要があります。次に例を示します。

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

サービスポート名には、name: protocol[-suffix] の構文で接尾辞を含めることができます。ここで、角かっこはダッシュで始まるオプションの接尾辞を示します。次に例を示します。

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

指標を Google Cloud コンソールに表示するには、サービスポートに http、http2、grpc のいずれかのプロトコルを指定する必要があります。https プロトコルによって名づけられたサービスポートは tcp として扱われ、これらのサービスの指標は表示されません。

サイドカー プロキシを挿入する

このセクションでは、Cloud Service Mesh を使用してサイドカー プロキシ インジェクションを構成し、ネットワーク セキュリティ、信頼性、オブザーバビリティを強化する方法について説明します。これらの機能が、アプリケーションのプライマリ コンテナと分離されて抽象化され、同じ Pod 内に別のコンテナとして提供される、共通のプロセス外プロキシ（サイドカー）に実装されます。本番環境のアプリケーションを再設計することなく、サービス メッシュに参加する Cloud Service Mesh の機能を使用できます。

自動サイドカー プロキシ インジェクション（自動インジェクション）は、Cloud Service Mesh がワークロードの Pod 用に構成した名前空間ラベルを検出すると実行されます。プロキシは、ワークロードのすべての受信トラフィックと送信トラフィックを傍受し、Cloud Service Mesh と通信します。

これらのタスクに必要な権限

このページのタスクを実行するには、roles/container.clusterAdmin 以上のロールが必要です。このロールに含まれる権限の詳細については、Google Kubernetes Engine のロールをご覧ください。

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

1. インジェクションの名前空間を有効にします。手順は、コントロール プレーンの実装によって異なります。

   マネージド（TD）

   1. デフォルトのインジェクション ラベルを名前空間に適用します。

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

   マネージド（Istiod）

   推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。

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

   マネージド Istiod コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。

   1. 利用可能なリリース チャンネルを探すには、次のコマンドを実行します。

      kubectl -n istio-system get controlplanerevision
      

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

      NAME                AGE
      asm-managed-rapid   6d7h
      

      注: 上記のリストに 2 つのコントロール プレーンのリビジョンが表示されている場合は、1 つを削除します。クラスタに複数のコントロール プレーン チャネルを配置することはできません。

      出力で、NAME 列の値は、Cloud Service Mesh バージョンで使用可能なリリース チャンネルに対応するリビジョン ラベルです。

   2. リビジョン ラベルを名前空間に適用します。

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

   クラスタ内

   推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを名前空間に適用します。

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

   デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションがサポートされています。 次の手順を使用します。

   1. 次のコマンドを使用して、istiod のリビジョン ラベルを探します。

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. リビジョン ラベルを名前空間に適用します。次のコマンドで、REVISION_LABEL は前の手順でメモした istiod リビジョン ラベルの値です。

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

2. 次のセクションの手順に沿って、該当する Pod を再起動します。

3. demo 名前空間にアノテーションを次のように追加します。

   kubectl annotate --overwrite namespace NAMESPACE \
   mesh.cloud.google.com/proxy='{"managed":"true"}'
   

Pod を再起動してサイドカー プロキシを更新する

警告: Blue / Green デプロイのロードバランサまたはルーターを設定していない場合を除いて、必ずステージング環境で Pod の再起動をテストし、サービスがトラフィックの中断に対処できることを確認するようにしてください。

自動サイドカー インジェクションでは、Pod の再起動で既存の Pod のサイドカーを更新できます。

Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。

1. Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。

   kubectl rollout restart deployment -n NAMESPACE

   Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。

   kubectl delete pod -n NAMESPACE --all

2. 名前空間内のすべての Pod にサイドカーが挿入されたことを確認します。

   kubectl get pod -n NAMESPACE

   次に前のコマンドの出力例を示します。ここで、READY 列はワークロードごとに 2 つのコンテナ（プライマリ コンテナとサイドカー プロキシのコンテナ）があることを示しています。

   NAME                    READY   STATUS    RESTARTS   AGE
   WORKLOAD           2/2     Running   0          20s
   ...