Kubernetes ワークロードをオンボーディングする
このページでは、Cloud Service Mesh で Kubernetes ワークロードをオンボーディングする方法について説明します。
Kubernetes Service をデプロイする
Cloud Service Mesh を使用するクラスタに Kubernetes Service をデプロイするには、次の操作を行う必要があります。
- すべてのコンテナに Kubernetes Service を作成します。すべての Deployment に接続された Kubernetes Service がそれぞれ存在することになります。 
- Service ポートに名前を付けます。GKE では名前のない Service ポートを定義できますが、Cloud Service Mesh ではポートのプロトコルと一致するポートの名前を指定する必要があります。 
- Deployment にラベルを付けます。これにより、同じサービスの複数のバージョン間でトラフィックを分割するなど、Cloud Service Mesh のトラフィック管理機能を使用できます。 
次の Deployment と Service の例は、上述の要件を示しています。
Cloud Service Mesh が有効なクラスタに Service をデプロイしたら、必ずサイドカー プロキシを挿入してください。
例: Online Boutique のサンプルをデプロイする
anthos-service-mesh-packages リポジトリの Online Boutique サンプル アプリケーションは、microservices-demo リポジトリの元のマニフェスト セットから変更されています。ベスト プラクティスに従い、各 Service は、一意のサービス アカウントを持つ個別の Namespace にデプロイします。
- アプリケーションの Namespace を作成します。 - 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
- インジェクションの Namespace を有効にします。手順は、コントロール プレーンの実装によって異なります。 - マネージド(TD)- デフォルトのインジェクション ラベルを Namespace に適用します。 - 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)- 推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを Namespace に適用します。 - 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 コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。 - 次のコマンドを実行して、利用可能なリリース チャンネルを探します。 - kubectl -n istio-system get controlplanerevision- 出力は次のようになります。 - NAME AGE asm-managed-rapid 6d7h- 出力の - NAME列の値は、Cloud Service Mesh バージョンで使用可能なリリース チャンネルに対応するリビジョン ラベルです。
- リビジョン ラベルを名前空間に適用します。 - 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;
 - クラスタ内- 推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを Namespace に適用します。 - 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のリビジョン ラベルを探します。- kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
- リビジョン ラベルを Namespace に適用します。次のコマンドで、 - 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;
 
- サンプル アプリケーションをクラスタにデプロイします。 - サービス アカウントとデプロイを作成します。 - 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
- サービスを作成します。 - 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
- サービス エントリを作成します。 - 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 のいずれか 1 つのプロトコルを含む名前をサービスポートに付ける必要があります。https プロトコルによって名づけられたサービスポートは tcp として扱われ、これらのサービスの指標は表示されません。
サイドカー プロキシを挿入する
このセクションでは、Cloud Service Mesh を使用してサイドカー プロキシ インジェクションを構成し、ネットワーク セキュリティ、信頼性、オブザーバビリティを強化する方法について説明します。これらの機能は、アプリケーションのプライマリ コンテナから分離されて抽象化され、同じ Pod 内に別のコンテナとして提供される、共通のプロセス外プロキシ(サイドカー)に実装されます。本番環境のアプリケーションを再設計することなく、Cloud Service Mesh の機能を使用してサービス メッシュに参加できます。
自動サイドカー プロキシ インジェクション(自動インジェクション)は、Cloud Service Mesh がワークロードの Pod 用に構成した Namespace ラベルを検出すると実行されます。プロキシは、ワークロードへのすべてのインバウンド トラフィックとアウトバウンド トラフィックをインターセプトし、Cloud Service Mesh と通信します。
自動サイドカー インジェクションを有効にする
- インジェクションの Namespace を有効にします。手順は、コントロール プレーンの実装によって異なります。 - マネージド(TD)- デフォルトのインジェクション ラベルを Namespace に適用します。
 - kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite- マネージド(Istiod)- 推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを Namespace に適用します。 - kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite- マネージド Istiod コントロール プレーンを使用している既存のユーザーの場合: デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。次の手順を行います。 - 次のコマンドを実行して、利用可能なリリース チャンネルを探します。 - kubectl -n istio-system get controlplanerevision- 出力は次のようになります。 - NAME AGE asm-managed-rapid 6d7h- 注: 上記のリストにコントロール プレーンのリビジョンが 2 つ表示されている場合は、一方を削除します。クラスタに複数のコントロール プレーン チャネルを配置することはできません。 - 出力の - NAME列の値は、Cloud Service Mesh バージョンで使用可能なリリース チャンネルに対応するリビジョン ラベルです。
- リビジョン ラベルを名前空間に適用します。 - kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
 - クラスタ内- 推奨: 次のコマンドを実行して、デフォルトのインジェクション ラベルを Namespace に適用します。 - kubectl label namespace NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite- デフォルトのインジェクションを使用することをおすすめしますが、リビジョンベースのインジェクションもサポートされています。 次の手順で対応します。 - 次のコマンドを使用して、 - istiodのリビジョン ラベルを探します。- kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
- リビジョン ラベルを Namespace に適用します。次のコマンドで、 - REVISION_LABELは前の手順で確認した- istiodリビジョン ラベルの値です。- kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
 
- 次のセクションの手順に沿って、該当する Pod を再起動します。 
- demoNamespace に、次のようにアノテーションを追加します。- kubectl annotate --overwrite namespace NAMESPACE \ mesh.cloud.google.com/proxy='{"managed":"true"}'
Pod を再起動してサイドカー プロキシを更新する
自動サイドカー インジェクションでは、Pod の再起動で既存の Pod のサイドカーを更新できます。
Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。
- Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。 - kubectl rollout restart deployment -n NAMESPACE - Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。 - kubectl delete pod -n NAMESPACE --all 
- Namespace 内のすべての Pod にサイドカーが挿入されたことを確認します。 - kubectl get pod -n NAMESPACE - 次に前のコマンドの出力例を示します。ここで、 - READY列はワークロードごとに 2 つのコンテナ(プライマリ コンテナとサイドカー プロキシのコンテナ)があることを示しています。- NAME READY STATUS RESTARTS AGE WORKLOAD 2/2 Running 0 20s ...