マネージド Kubernetes に Windows アプリケーションをデプロイする

Last reviewed 2024-08-14 UTC

このドキュメントでは、マネージド Kubernetes で実行される Windows アプリケーションのネットワークの管理とスケーリングで説明されているリファレンス アーキテクチャをデプロイする方法について説明します。

この手順は、Google Kubernetes Engine（GKE）クラスタで実行される Windows アプリケーションの設計と管理を担当するクラウド アーキテクト、ネットワーク管理者、IT 担当者を対象としています。

アーキテクチャ

次の図は、マネージド GKE クラスタで実行される Windows アプリケーションをデプロイするときに使用するリファレンス アーキテクチャを示しています。

上の図で、矢印は、Cloud Service Mesh と Envoy ゲートウェイを使用して GKE 上で実行される Windows アプリケーションのネットワーキングを管理するワークフローを表しています。リージョン GKE クラスタには、Windows ノードプールと Linux ノードプールの両方が含まれます。Cloud Service Mesh は、Windows Pod へのトラフィック ルートを作成して管理します。

目標

• Windows アプリケーションと Envoy プロキシを実行する GKE クラスタを作成して設定する。
• Windows アプリケーションをデプロイして検証する。
• Envoy ゲートウェイのコントロール プレーンとして Cloud Service Mesh を構成する。
• Kubernetes Gateway API を使用して、内部アプリケーション ロードバランサをプロビジョニングし、Envoy ゲートウェイを公開する。
• 作成した継続的デプロイ オペレーションについて理解する。

費用

このアーキテクチャのデプロイでは、課金対象である次の Google Cloud コンポーネントを使用します。

• Cloud Load Balancing
• Google Kubernetes Engine
• Cloud Service Mesh

このデプロイの終了後は、作成したリソースを削除するとそれ以上の請求が発生しなくなります。詳細については、クリーンアップをご覧ください。

始める前に

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

3. Enable the Cloud Shell, and Cloud Service Mesh APIs.

   Enable the APIs

4. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

共有 Virtual Private Cloud（VPC）環境で実行する場合は、Cloud Load Balancing の応答性チェックのため、プロキシ専用のサブネットとファイアウォール ルールを手動で作成する手順も実施する必要があります。

GKE クラスタを作成する

次の手順で GKE クラスタを作成します。GKE クラスタを使用して、このデプロイで Windows アプリケーションと Envoy プロキシを保持して実行します。

1. Cloud Shell で、次の Google Cloud CLI コマンドを実行して、3 つのリージョンにそれぞれ 1 つのノードを持つリージョン GKE クラスタを作成します。

   gcloud container clusters create my-cluster
       --enable-ip-alias \
       --num-nodes=1 \
       --release-channel stable \
       --enable-dataplane-v2 \
       --region us-central1 \
       --scopes=cloud-platform \
       --gateway-api=standard
   

2. Windows ノードプールを GKE クラスタに追加します。

   gcloud container node-pools create win-pool \
       --cluster=my-cluster \
       --image-type=windows_ltsc_containerd \
       --no-enable-autoupgrade \
       --region=us-central1 \
       --num-nodes=1 \
       --machine-type=n1-standard-2 \
       --windows-os-version=ltsc2019
   

   このオペレーションが完了するまでに 20 分ほどかかることがあります。

3. Google Cloud プロジェクト ID を環境変数に保存します。

   export PROJECT_ID=$(gcloud config get project)
   

4. GKE クラスタに接続します。

   gcloud container clusters get-credentials my-cluster --region us-central1
   

5. GKE クラスタ内のすべてのノードを一覧表示します。

   kubectl get nodes
   

   出力には、3 つの Linux ノードと 3 つの Windows ノードが表示されます。

   GKE クラスタの準備ができたら、2 つの Windows ベースのテスト アプリケーションをデプロイできます。

2 つのテスト アプリケーションをデプロイする

このセクションでは、2 つの Windows ベースのテスト アプリケーションをデプロイします。どちらのテスト アプリケーションも、アプリケーションが実行されているホスト名を出力します。また、スタンドアロン ネットワーク エンドポイント グループ（NEG）を介してアプリケーションを公開する Kubernetes Service も作成します。

リージョン クラスタに Windows ベースのアプリケーションと Kubernetes Service をデプロイすると、アプリケーションが実行されるゾーンごとに NEG が作成されます。このデプロイガイドでは、これらの NEG を Cloud Service Mesh サービスのバックエンドとして構成する方法について説明します。

1. Cloud Shell で、kubectl を使用して次の YAML ファイルを適用し、最初のテスト アプリケーションをデプロイします。このコマンドは、テスト アプリケーションのインスタンスを 3 つ（リージョン ゾーンごとに 1 つ）デプロイします。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: win-webserver-1
     name: win-webserver-1
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: win-webserver-1
     template:
       metadata:
         labels:
           app: win-webserver-1
         name: win-webserver-1
       spec:
        containers:
         - name: windowswebserver
           image: k8s.gcr.io/e2e-test-images/agnhost:2.36
           command: ["/agnhost"]
           args: ["netexec", "--http-port", "80"]
        topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: kubernetes.io/hostname
           whenUnsatisfiable: DoNotSchedule
           labelSelector:
             matchLabels:
               app: win-webserver-1
        nodeSelector:
         kubernetes.io/os: windows
   

2. 一致する Kubernetes Service を適用し、NEG で公開します。

   apiVersion: v1
   kind: Service
   metadata:
     name: win-webserver-1
     annotations:
       cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}'
   spec:
     type: ClusterIP
     selector:
       app: win-webserver-1
     ports:
     - name: http
       protocol: TCP
       port: 80
       targetPort: 80
   

3. デプロイを確認します。

   kubectl get pods
   

   出力には、アプリケーションに実行中の Windows Pod が 3 つあることが示されます。

   NAME                               READY   STATUS    RESTARTS   AGE
   win-webserver-1-7bb4c57f6d-hnpgd   1/1     Running   0          5m58s
   win-webserver-1-7bb4c57f6d-rgqsb   1/1     Running   0          5m58s
   win-webserver-1-7bb4c57f6d-xp7ww   1/1     Running   0          5m58s
   

4. Kubernetes Service が作成されたことを確認します。

   $ kubectl get svc
   

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

   NAME              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
   kubernetes        ClusterIP   10.64.0.1            443/TCP   58m
   win-webserver-1   ClusterIP   10.64.6.20           80/TCP    3m35s
   

5. kubectl に対して describe コマンドを実行し、アプリケーションが実行されている各ゾーンで Kubernetes Service に対応する NEG が作成されていることを確認します。

   $ kubectl describe service win-webserver-1
   

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

   Name:              win-webserver-1
   Namespace:         default
   Labels:            
   Annotations:       cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}}
                      cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}
   Selector:          app=win-webserver-1
   Type:              ClusterIP
   IP Family Policy:  SingleStack
   IP Families:       IPv4
   IP:                10.64.6.20
   IPs:               10.64.6.20
   Port:              http  80/TCP
   TargetPort:        80/TCP
   Endpoints:         10.60.3.5:80,10.60.4.5:80,10.60.5.5:80
   Session Affinity:  None
   Events:
     Type    Reason  Age    From            Message
     ----    ------  ----   ----            -------
     Normal  Create  4m25s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a".
     Normal  Create  4m18s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b".
     Normal  Create  4m11s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c".
     Normal  Attach  4m9s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a")
     Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c")
     Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b")
   

   上記のコマンドの出力は、ゾーンごとに NEG が作成されたことを示しています。

6. 省略可: gcloud CLI を使用して NEG が作成されたことを確認します。

   gcloud compute network-endpoint-groups list
   

   出力は次のとおりです。

   NAME                                                        LOCATION            ENDPOINT_TYPE     SIZE
   win-webserver-1                                us-central1-a  GCE_VM_IP_PORT  1
   win-webserver-1                                us-central1-b  GCE_VM_IP_PORT  1
   win-webserver-1                                us-central1-c  GCE_VM_IP_PORT  1
   

7. 2 番目のテストアプリケーションをデプロイするには、次の YAML ファイルを適用します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: win-webserver-2
     name: win-webserver-2
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: win-webserver-2
     template:
       metadata:
         labels:
           app: win-webserver-2
         name: win-webserver-2
       spec:
        containers:
         - name: windowswebserver
           image: k8s.gcr.io/e2e-test-images/agnhost:2.36
           command: ["/agnhost"]
           args: ["netexec", "--http-port", "80"]
        topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: kubernetes.io/hostname
           whenUnsatisfiable: DoNotSchedule
           labelSelector:
             matchLabels:
               app: win-webserver-2
        nodeSelector:
         kubernetes.io/os: windows
   

8. 対応する Kubernetes Service を作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: win-webserver-2
     annotations:
       cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}'
   spec:
     type: ClusterIP
     selector:
       app: win-webserver-2
     ports:
     - name: http
       protocol: TCP
       port: 80
       targetPort: 80
   

9. アプリケーションのデプロイを確認します。

   kubectl get pods
   

   出力を確認して、実行中の Pod が 3 つあることを確認します。

10. Kubernetes Service と 3 つの NEG が作成されていることを確認します。

    kubectl describe service win-webserver-2
    

Cloud Service Mesh を構成する

このセクションでは、Cloud Service Mesh を Envoy ゲートウェイのコントロール プレーンとして構成します。

Envoy ゲートウェイを関連する Cloud Service Mesh ルーティング構成にマッピングするには、scope_name パラメータを指定します。scope_name パラメータを使用すると、さまざまな Envoy ゲートウェイにさまざまなルーティング ルールを構成できます。

1. Cloud Shell で、アプリケーションの応答性をチェックしている Google サービスからの受信トラフィックを許可するようにファイアウォール ルールを作成します。

   gcloud compute firewall-rules create allow-health-checks \
     --network=default \
     --direction=INGRESS \
     --action=ALLOW \
     --rules=tcp \
     --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"
   

2. 最初のアプリケーションの応答性を確認します。

   gcloud compute health-checks create http win-app-1-health-check \
     --enable-logging \
     --request-path="/healthz" \
     --use-serving-port
   

3. 2 番目のアプリケーションの応答性を確認します。

   gcloud compute health-checks create http win-app-2-health-check \
     --enable-logging \
     --request-path="/healthz" \
     --use-serving-port
   

4. 最初のアプリケーションの Cloud Service Mesh バックエンド サービスを作成します。

   gcloud compute backend-services create win-app-1-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --port-name=http \
    --health-checks win-app-1-health-check
   

5. 2 番目のアプリケーションの Cloud Service Mesh バックエンド サービスを作成します。

   gcloud compute backend-services create win-app-2-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --port-name=http \
    --health-checks win-app-2-health-check
   

6. 前に作成した NEG を追加します。これらの NEG は、Cloud Service Mesh バックエンド サービスのバックエンドとして作成した最初のアプリケーションに関連付けられます。このコードサンプルでは、作成したリージョン クラスタのゾーンごとに NEG を 1 つ追加します。

   BACKEND_SERVICE=win-app-1-service
   APP1_NEG_NAME=win-webserver-1
   MAX_RATE_PER_ENDPOINT=10
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-b \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP1_NEG_NAME \
     --network-endpoint-group-zone us-central1-c \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   

7. NEG を追加します。これらの NEG は、Cloud Service Mesh バックエンド サービスのバックエンドとして作成した 2 番目のアプリケーションに関連付けられています。このコードサンプルでは、作成したリージョン クラスタのゾーンごとに NEG を 1 つ追加します。

   BACKEND_SERVICE=win-app-2-service
   APP2_NEG_NAME=win-webserver-2
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-b \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   
   gcloud compute backend-services add-backend $BACKEND_SERVICE \
     --global \
     --network-endpoint-group $APP2_NEG_NAME \
     --network-endpoint-group-zone us-central1-c \
     --balancing-mode RATE \
     --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT
   

追加の Cloud Service Mesh リソースを構成する

Cloud Service Mesh サービスを構成したので、Cloud Service Mesh の設定を完了するために、さらに 2 つのリソースを構成する必要があります。

まず、Gateway リソースを構成する手順を示します。Gateway リソースは、Cloud Service Mesh ルーティング ルールの生成に使用される仮想リソースです。Cloud Service Mesh のルーティング ルールは、Envoy プロキシをゲートウェイとして構成するために使用されます。

次の手順では、各バックエンド サービスに HTTPRoute リソースを構成する方法を示します。HTTPRoute リソースは、HTTP リクエストを関連するバックエンド サービスにマッピングします。

1. Cloud Shell で、Gateway リソースを定義する gateway.yaml という名前の YAML ファイルを作成します。

   cat <<EOF> gateway.yaml
   name: gateway80
   scope: gateway-proxy
   ports:
   - 8080
   type: OPEN_MESH
   EOF
   

2. gateway.yaml ファイルを呼び出して Gateway リソースを作成します。

   gcloud network-services gateways import gateway80 \
     --source=gateway.yaml \
     --location=global
   

   Gateway の名前は projects/$PROJECT_ID/locations/global/gateways/gateway80 になります。

   この Gateway 名は、各バックエンド サービスに対して HTTPRoutes を作成するときに使用します。

バックエンド サービスごとに HTTPRoutes を作成する:

1. Cloud Shell で、Google Cloud プロジェクト ID を環境変数に格納します。

   export PROJECT_ID=$(gcloud config get project)
   

2. 最初のアプリケーションの HTTPRoute YAML ファイルを作成します。

   cat <<EOF> win-app-1-route.yaml
   name: win-app-1-http-route
   hostnames:
   - win-app-1
   gateways:
   - projects/$PROJECT_ID/locations/global/gateways/gateway80
   rules:
   - action:
      destinations:
      - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service"
   EOF
   

3. 最初のアプリケーションの HTTPRoute リソースを作成します。

   gcloud network-services http-routes import win-app-1-http-route \
     --source=win-app-1-route.yaml \
     --location=global
   

4. 2 番目のアプリケーションの HTTPRoute YAML ファイルを作成します。

   cat <<EOF> win-app-2-route.yaml
   name: win-app-2-http-route
   hostnames:
   - win-app-2
   gateways:
   - projects/$PROJECT_ID/locations/global/gateways/gateway80
   rules:
   - action:
      destinations:
    - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service"
   EOF
   

5. 2 番目のアプリケーションの HTTPRoute リソースを作成します。

   gcloud network-services http-routes import win-app-2-http-route \
     --source=win-app-2-route.yaml \
     --location=global
   

Envoy ゲートウェイをデプロイして公開する

2 つの Windows ベースのテスト アプリケーションと Cloud Service Mesh を作成したら、デプロイの YAML ファイルを作成して Envoy ゲートウェイをデプロイします。このデプロイの YAML ファイルは、次のタスクを実行します。

• Envoy ゲートウェイをブートストラップします。
• Cloud Service Mesh をコントロール プレーンとして使用するように Envoy ゲートウェイを構成します。
• Gateway80 という名前のゲートウェイに HTTPRoutes を使用するように Envoy ゲートウェイを構成します。

レプリカ Envoy ゲートウェイを 2 つデプロイします。このアプローチにより、ゲートウェイのフォールト トレラントで冗長性を確保できます。負荷に基づいて Envoy ゲートウェイを自動的にスケーリングするには、必要に応じて HorizontalPodAutoscaler を構成します。Horizontal Pod Autoscaler を構成する場合は、水平 Pod 自動スケーリングの構成の説明に従って操作します。

1. Cloud Shell で、YAML ファイルを作成します。

   apiVersion: apps/v1
   kind: Deployment
       metadata:
     creationTimestamp: null
     labels:
       app: td-envoy-gateway
     name: td-envoy-gateway
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: td-envoy-gateway
     template:
       metadata:
         creationTimestamp: null
         labels:
           app: td-envoy-gateway
       spec:
         containers:
         - name: envoy
           image: envoyproxy/envoy:v1.21.6
           imagePullPolicy: Always
           resources:
             limits:
               cpu: "2"
               memory: 1Gi
             requests:
               cpu: 100m
               memory: 128Mi
           env:
           - name: ENVOY_UID
             value: "1337"
           volumeMounts:
             - mountPath: /etc/envoy
               name: envoy-bootstrap
         initContainers:
         - name: td-bootstrap-writer
           image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator
           imagePullPolicy: Always
           args:
             - --project_number='my_project_number'
             - --scope_name='gateway-proxy'
             - --envoy_port=8080
             - --bootstrap_file_output_path=/var/lib/data/envoy.yaml
             - --traffic_director_url=trafficdirector.googleapis.com:443
             - --expose_stats_port=15005
           volumeMounts:
             - mountPath: /var/lib/data
               name: envoy-bootstrap
         volumes:
           - name: envoy-bootstrap
             emptyDir: {}
   

   • my_project_number は、使用するプロジェクト番号に置き換えます。

     • プロジェクト番号は、次のコマンドで確認できます。

     gcloud projects describe $(gcloud config get project)
      --format="value(projectNumber)"
     

   ポート 15005 は、/stats という名前の Envoy Admin エンドポイントを公開するために使用されます。また、次の目的にも使用されます。

   • 内部アプリケーション ロードバランサからの応答性チェック用のエンドポイントとして。
   • Envoy から Google Cloud Managed Service for Prometheus の指標を使用するため。

   2 つの Envoy Gateway Pod が実行されたら、ClusterIP タイプの Service を作成して公開します。また、BackendConfig という YAML ファイルを作成する必要があります。BackendConfig は、標準以外の応答性チェックを定義します。このチェックは、Envoy ゲートウェイの応答性を確認するために使用されます。

2. 標準以外の応答性チェックを使用してバックエンド構成を作成するには、envoy-backendconfig という名前の YAML ファイルを作成します。

   apiVersion: cloud.google.com/v1
   kind: BackendConfig
   metadata:
     name: envoy-backendconfig
   spec:
     healthCheck:
       checkIntervalSec: 5
       timeoutSec: 5
       healthyThreshold: 2
       unhealthyThreshold: 3
       type: HTTP
       requestPath: /stats
       port: 15005
   

   応答性チェックでは、ポート 15005 の /stats エンドポイントを使用して、Envoy ゲートウェイの応答性を継続的に確認します。

3. Envoy ゲートウェイ サービスを作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: td-envoy-gateway
     annotations:
       cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}'
   spec:
     type: ClusterIP
     selector:
       app: td-envoy-gateway
     ports:
     - name: http
       protocol: TCP
       port: 8080
       targetPort: 8080
     - name: stats
       protocol: TCP
       port: 15005
       targetPort: 15005
   

4. 作成した Envoy ゲートウェイ サービスを表示します。

   kubectl get svc td-envoy-gateway
   

Kubernetes Gateway リソースを作成する

Kubernetes Gateway リソースを作成すると、内部アプリケーション ロードバランサがプロビジョニングされ、Envoy ゲートウェイが公開されます。

このリソースを作成する前に、2 つのサンプルの自己署名証明書を作成し、Kubernetes Secret として GKE クラスタにインポートする必要があります。証明書により、次のゲートウェイ アーキテクチャが有効になります。

• 各アプリケーションは HTTPS 経由で提供されます。
• 各アプリケーションは専用の証明書を使用します。

セルフマネージド証明書を使用する場合、内部アプリケーション ロードバランサは、証明書の最大数まで証明書を使用して、異なる完全修飾ドメイン名を持つアプリケーションを公開できます。

証明書を作成するには、openssl を使用します。

1. Cloud Shell で、最初の証明書の構成ファイルを生成します。

   cat <<EOF >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = win-webserver-1.example.com
   [sans_list]
   DNS.1                     = win-webserver-1.example.com
   EOF
   

2. 最初の証明書の秘密鍵を生成します。

   openssl genrsa -out sample_private_key 2048
   

3. 証明書リクエストを生成します。

   openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE
   

4. 署名して最初の証明書を生成します。

   openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt     -extfile CONFIG_FILE -extensions extension_requirements -days 90
   

5. 2 番目の証明書の構成ファイルを生成します。

   cat <<EOF >CONFIG_FILE2
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = win-webserver-2.example.com
   [sans_list]
   DNS.1                     = win-webserver-2.example.com
   EOF
   

6. 2 番目の証明書の秘密鍵を生成します。

   openssl genrsa -out sample_private_key2 2048
   

7. 証明書リクエストを生成します。

   openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2
   

8. 2 番目の証明書に署名して生成します。

   openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt     -extfile CONFIG_FILE2 -extensions extension_requirements -days 90
   

証明書を Kubernetes Secret としてインポートする

このセクションでは、次のタスクを行います。

• 自己署名証明書を Kubernetes Secret として GKE クラスタにインポートします。
• 内部 VPC に静的 IP アドレスを作成します。
• Kubernetes Gateway API リソースを作成します。
• 証明書が機能していることを確認します。

1. Cloud Shell で、最初の証明書を Kubernetes Secret としてインポートします。

   kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key
   

2. 2 番目の証明書を Kubernetes Secret としてインポートします。

   kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2
   

3. 内部アプリケーション ロードバランサを有効にするには、内部 VPC に静的 IP アドレスを作成します。

   gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default
   

4. Kubernetes Gateway API リソースの YAML ファイルを作成します。

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-https
   spec:
     gatewayClassName: gke-l7-rilb
     addresses:
       - type: NamedAddress
         value: sample-ingress-ip
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs:
         - name: sample-cert
         - name: sample-cert-2
   

   デフォルトでは、Kubernetes Gateway にデフォルトのルートは設定されていません。リクエストが送信されると、ゲートウェイは「ページが見つかりません（404）」エラーを返します。

5. すべての受信リクエストを Envoy ゲートウェイに渡す Kubernetes Gateway のデフォルト route YAML ファイルを構成します。

     kind: HTTPRoute
     apiVersion: gateway.networking.k8s.io/v1beta1
     metadata:
       name: envoy-default-backend
     spec:
       parentRefs:
       - kind: Gateway
         name: internal-https
       rules:
       - backendRefs:
         - name: td-envoy-gateway
           port: 8080
   

   両方のアプリケーションに HTTP リクエストを送信して、フロー全体を確認します。Envoy ゲートウェイが正しいアプリケーション Pod にトラフィックを転送することを確認するには、HTTP Host ヘッダーを調べます。

6. Kubernetes Gateway の IP アドレスを見つけて、環境変数に格納します。

   export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)
   

7. 最初のアプリケーションにリクエストを送信します。

   curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName
   

8. 2 番目のアプリケーションにリクエストを送信します。

   curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName
   

9. リクエストから返されたホスト名が、win-app-1 と win-app-2 を実行している Pod と一致することを確認します。

   kubectl get pods
   

   出力には win-app-1 と win-app-2 が表示されます。

Envoy ゲートウェイをモニタリングする

Google Cloud Managed Service for Prometheus を使用して Envoy ゲートウェイをモニタリングします。

前に作成したクラスタでは、Google Cloud Managed Service for Prometheus がデフォルトで有効になっているはずです。

1. Cloud Shell で、次の YAML ファイルを適用して PodMonitoring リソースを作成します。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-envoy
   spec:
     selector:
       matchLabels:
         app: td-envoy-gateway
     endpoints:
     - port: 15005
       interval: 30s
       path: /stats/prometheus
   

   YAML ファイルを適用すると、ダッシュボードで Google Cloud Managed Service for Prometheus の指標の収集が開始します。

2. Google Cloud Managed Service for Prometheus の指標ダッシュボードを作成するには、次の操作を行います。

   1. Google Cloud コンソールにログインします。
   2. メニューを開きます。
   3. [オペレーション] > [Monitoring] > [ダッシュボード] をクリックします。

3. ダッシュボードをインポートする手順は次のとおりです。

   1. [ダッシュボード] 画面で、[サンプル ライブラリ] をクリックします。
   2. フィルタ ボックスに「envoy」と入力します。
   3. [Istio Envoy Prometheus Overview] をクリックします。
   4. チェックボックスをオンにします。
   5. [インポート]、[確認] の順にクリックして、ダッシュボードをインポートします。

4. ダッシュボードを表示する手順は次のとおりです。

   1. [ダッシュボード リスト] をクリックします。
   2. [統合] を選択します。
   3. [Istio Envoy Prometheus Overview] をクリックしてダッシュボードを表示します。

Envoy ゲートウェイの最も重要な指標を確認できるようになりました。条件に基づいてアラートを構成することもできます。クリーンアップする前に、アプリケーションにテスト リクエストをさらにいくつか送信し、最新の指標でダッシュボードがどのように更新されるかを確認します。

クリーンアップ

このデプロイで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

• このデプロイガイドで使用する Google Cloud プロダクトの詳細を確認する。
  • GKE ネットワーキングのベスト プラクティス
  • Cloud Service Mesh コントロール プレーンのオブザーバビリティ
  • ロードバランサでセルフマネージド SSL 証明書を使用する
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

寄稿者

作成者: Eitan Eibschutz | スタッフ テクニカル ソリューション コンサルタント

その他の寄稿者:

• John Laham | ソリューション アーキテクト
• Kaslin Fields | デベロッパー アドボケイト
• Maridi (Raju) Makaraju | サポート性に関するテクニカル リーダー
• Valavan Rajakumar | キー エンタープライズ アーキテクト
• Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング