このページは Cloud Translation API によって翻訳されました。

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

Last reviewed 2024-08-14 UTC

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

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

アーキテクチャ

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

データは、内部アプリケーションロードバランサと Envoy ゲートウェイを通過します。

上の図で、矢印は、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コンポーネントを使用します。

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

始める前に

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
Verify that billing is enabled for your Google Cloud project.
Enable the Cloud Shell, and Cloud Service Mesh APIs.
Enable the APIs
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 アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトの削除
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 プロダクトの詳細を確認する。
- Cloud アーキテクチャセンターで、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。
寄稿者
作成者: Eitan Eibschutz | スタッフテクニカルソリューションコンサルタント
その他の寄稿者:
- John Laham | ソリューションアーキテクト
- Kaslin Fields | デベロッパーアドボケイト
- Maridi (Raju) Makaraju | サポート性に関するテクニカルリーダー
- Valavan Rajakumar | キーエンタープライズアーキテクト
- Victor Moreno | プロダクトマネージャー、クラウドネットワーキング

マネージド Kubernetes に Windows アプリケーションをデプロイする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

アーキテクチャ

目標

費用

始める前に

GKE クラスタを作成する

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

Cloud Service Mesh を構成する

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

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

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

Kubernetes Gateway リソースを作成する

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

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

クリーンアップ

プロジェクトの削除

次のステップ

寄稿者

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

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

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