Windows Server アプリケーションのデプロイ

Standard

このページでは、ステートレスの Windows Server アプリケーションを Google Kubernetes Engine（GKE）クラスタにデプロイする方法について説明します。また、ステートフル Windows アプリケーションをデプロイする方法についても学習します。

始める前に

作業を始める前に、次のことを確認してください。

Artifact Registry API と Google Kubernetes Engine API を有効にします。

API を有効にする

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

パブリックノードを含むクラスタに Windows Server アプリケーションをデプロイする

パブリックノードのみを含む GKE クラスタに Windows Server アプリケーションをデプロイするには、次のタスクを行う必要があります。

公開ノードを含むクラスタを作成する。
Deployment マニフェストファイルを作成する。
Deployment を作成して公開する。
Pod が動作していることを確認する。

パブリックノードを含むクラスタを作成する

Windows Server ノードプールを使用する GKE クラスタをすでにお持ちの場合は、次のステップに進みます。お持ちでない場合は、Windows Server ノードプールを使用してクラスタを作成します。外部 IP アドレスを持つノード（パブリックノード）をプロビジョニングするには、クラスタの作成時に --no-enable-private-nodes フラグを使用します。

Deployment マニフェストファイルを作成する

Windows Server ノードは Key-Value ペア node.kubernetes.io/os=windows:NoSchedule で taint が設定されています。

これにより、GKE スケジューラが Windows Server ノードで Linux コンテナを実行しようとしなくなります。Windows Server ノード上の Windows Server コンテナをスケジュールするには、マニフェストファイルに次のノードセレクタを含める必要があります。

nodeSelector:
 kubernetes.io/os: windows

クラスタで実行されるアドミッション Webhook は、この Windows ノードセレクタに新しいワークロードがあるかチェックします。新しいワークロードが発見された場合、次の許容値をワークロードに適用して、taint が設定された Windows Server ノードで動作できるようにします。

tolerations:
- effect: NoSchedule
  key: node.kubernetes.io/os
  operator: Equal
  value: windows

場合によっては、この許容値をマニフェストファイルに明示的に含める必要があります。たとえば、クラスタ内のすべての Linux ノードと Windows Server ノードで実行するマルチアーキテクチャコンテナイメージを含む DaemonSet をデプロイする場合、マニフェストファイルに Windows ノードセレクタは含まれません。Windows taint の許容値を明示的に含める必要があります。

マニフェストファイルの例

次のサンプル Deployment ファイル（iis.yaml）は、Microsoft の IIS イメージを単一の Pod にデプロイします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80

このファイルは、すべてのワークロードが同じ Windows Server ノードイメージタイプとバージョンを使用するクラスタ向けです。混在ノードイメージの操作方法の詳細については、混在ノードイメージを使用するをご覧ください。

Deployment を作成して公開する

前のステップで作成した Deployment ファイルを、外部ロードバランサの Deployment を使用して Kubernetes Service として作成して公開します。

Deployment リソースを作成するには、次のコマンドを実行します。
```
kubectl apply -f iis.yaml
```
Deployment を外部ロードバランサとして公開するには、次のコマンドを実行します。
```
kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
```

Pod が実行されていることを確認する

Pod を検証して、機能していることを確認します。

kubectl を使用して、Pod のステータスを確認します。
```
kubectl get pods
```

返された出力で、Pod のステータスが Running になるまで待ちます。

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

サービスのステータスを取得し、EXTERNAL-IP フィールドに値が入力されるまで待ちます。

kubectl get service iis

次の出力が表示されます。

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s

これで、ブラウザを使用して http://EXTERNAL_IP を開き、IIS ウェブページを表示できます。

プライベートノードを含むクラスタに Windows Server アプリケーションをデプロイする

このセクションでは、プライベートノードのみで有効になっている GKE クラスタに Windows Server コンテナアプリケーションをデプロイする方法について説明します。

Windows Server コンテナイメージには複数のレイヤがあり、基本レイヤは Microsoft が提供しています。基本レイヤは、Linux Docker イメージレイヤのようにイメージに埋め込まれるのではなく、外部レイヤとして保存されます。Windows Server コンテナイメージを最初に pull するときに、通常、Microsoft サーバーから基本レイヤをダウンロードする必要があります。プライベートノードはインターネットに接続されないため、Windows Server の基本コンテナレイヤを Microsoft サーバーから直接 pull することはできません。

プライベートノードが有効になっているクラスタを使用するには、非分散レイヤを限定公開レジストリに push できるように Docker デーモンを構成します。詳細については、Docker の GitHub ページの Allow push of non-distributable artifacts をご覧ください。

プライベートノードが有効になっているクラスタに Windows Server アプリケーションをデプロイするには:

Windows Server ノードを含むクラスタを作成し、プライベートノードを有効にする。
Windows Server アプリケーションの Docker イメージをビルドする。
プライベートノードが有効になっているクラスタにアプリケーションをデプロイする。
Pod が動作していることを確認する。

プライベートノードを含むクラスタを作成する

Windows Server ノードを含むクラスタの作成の手順に沿って操作します。内部 IP アドレスのみを持つノード（プライベートノード）をプロビジョニングするには、クラスタの作成時に --enable-private-nodes フラグを使用します。

Windows Server アプリケーションの Docker イメージをビルドする

Docker イメージをビルドするには、アプリケーションコンテナを実行する Windows Server バージョン（Windows Server 2019、Windows Server バージョン 20H2 など）で Compute Engine インスタンスを起動します。また、インターネットに接続されていることを確認します。
Compute Engine インスタンスで、Docker デーモン config に移動します。
```
cat C:\ProgramData\docker\config\daemon.json
```
以下の行を追加して、外部レイヤを限定公開レジストリに push できるように Docker daemon.json ファイルを構成します。
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
この例では、REGISTRY_REGION-docker.pkg.dev は、イメージがホストされる Artifact Registry を意味します。
Docker デーモンを再起動します。
```
Restart-Service docker
```
Artifact Registry で Docker リポジトリを作成します。
アプリケーションの Docker イメージをビルドしてタグを付けします。
```
cd C:\my-app
```
```
docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
```
このコマンドを実行すると、Docker は現在のディレクトリにある Dockerfile を使用してイメージをビルドし、us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2 などの名前を使用してタグ付けします。
アプリケーションの Docker イメージをプロジェクトの Artifact Registry リポジトリに push します。allow-nondistributable-artifacts 構成を設定すると、Windows 基本レイヤが限定公開レジストリに push されます。
```
docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
```

Deployment マニフェストファイルを作成する

my-app.yaml という名前のサンプル Deployment マニフェストファイルを以下に示します。この例のイメージは、前のステップ（REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2）で push したイメージです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: my-server
        image: REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2

作成したクラスタで kubectl が動作するようにするには、get-credentials コマンドを使用します。
```
gcloud container clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME は、作成したクラスタの名前に置き換えます。
my-app.yaml ファイルで指定されているアプリケーションをプライベートクラスタにデプロイします。
```
kubectl apply -f my-app.yaml
```

Pod が実行されていることを確認する

すべての Pod を一覧表示して、アプリケーションが正しく実行されていることを確認します。

kubectl get pods

次の出力のように、Pod のステータスが Running と表示されます。

NAME                     READY   STATUS    RESTARTS   AGE
my-app-c95fc5596-c9zcb   1/1     Running   0          5m

混在ノードイメージを使用する

クラスタには、複数の Windows Server タイプと Windows Server バージョンのノードプールを含めることができます。また、Windows Server と Linux のワークロードを組み合わせることもできます。以下のセクションでは、これらのタイプのクラスタを使用するようにワークロードを構成する方法について詳しく説明します。

さまざまな Windows Server ノードイメージタイプでワークロードを使用する

さまざまな Windows Server イメージタイプを使用して、ノードプールをクラスタに追加できます。Windows Server タイプが混在するクラスタでは、互換性のない Windows Server ノードに Windows Server コンテナがスケジュールされていないことを確認する必要があります。

Windows Server LTSC ノードプールと Windows Server SAC ノードプールがある場合、両方のワークロードに gke-os-distribution ノードラベルを追加します。

Windows Server LTSC ワークロードのマニフェストファイルに、次の nodeSelector を追加します。

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc

Windows Server SAC ワークロードのマニフェストファイルに、次の nodeSelector を追加します。

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_sac

このラベルを追加すると、LTSC コンテナイメージが互換性のない SAC ノードにスケジュールされなくなり、その逆も同様です。

さまざまな Windows Server LTSC OS バージョンでワークロードを使用する

Windows Server ノードは、LTSC2022 と LTSC2019 OS イメージの両方をサポートしています。使用する Windows OS のバージョン（LTSC2022）は、nodeSelector の Key-Value ペア cloud.google.com/gke-windows-os-version=2022 で指定できます。

このノードラベルにより、GKE スケジューラは LTSC2022 または LTSC2019 ワークロードを実行するために、適切な Windows Server ノードを選択します。Windows Server ノードはどちらもイメージタイプ windows_ltsc_containerd に属します。ノードラベルの値は 2022 または 2019 です。ノードラベルが指定されていない場合、LTSC2019 または LTSC2022 の両方のノードを使用してコンテナをスケジュールできます。Windows Server コンテナを Windows Server LTSC2022 ノードでのみスケジュールするには、マニフェストファイルに次のノードセレクタを含める必要があります。

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc
   cloud.google.com/gke-windows-os-version: 2022

さまざまな Windows Server バージョンでワークロードを使用する

複数の異なる LTSC または SAC バージョンで Windows Server ノードプールを実行する必要がある場合は、クラスタで使用するすべての Windows Server バージョンで実行できるマルチアーキテクチャイメージとしてコンテナを構築することをおすすめします。gke-os-distribution ノードラベルは、互換性のないノードにワークロードがスケジュールされるのを防ぐのに十分ではありません。

クラスタで Linux と Windows Server のワークロードを使用する

次のノードセレクタを Linux ワークロードに追加して、常に Linux ノードにスケジュールされるようにします。

nodeSelector:
   kubernetes.io/os: linux

これにより、NoSchedule taint が誤って Windows Server ノードから削除された場合に、Linux ワークロードが Windows Server ノードにスケジュールされるのを防ぐことができます。

Windows Server アプリケーションのデプロイ

始める前に

パブリック ノードを含むクラスタに Windows Server アプリケーションをデプロイする

パブリック ノードを含むクラスタを作成する

Deployment マニフェスト ファイルを作成する

マニフェスト ファイルの例

Deployment を作成して公開する

Pod が実行されていることを確認する

プライベート ノードを含むクラスタに Windows Server アプリケーションをデプロイする

プライベート ノードを含むクラスタを作成する

Windows Server アプリケーションの Docker イメージをビルドする

Deployment マニフェスト ファイルを作成する

Pod が実行されていることを確認する

混在ノードイメージを使用する

さまざまな Windows Server ノードイメージ タイプでワークロードを使用する

さまざまな Windows Server LTSC OS バージョンでワークロードを使用する

さまざまな Windows Server バージョンでワークロードを使用する

クラスタで Linux と Windows Server のワークロードを使用する

パブリックノードを含むクラスタに Windows Server アプリケーションをデプロイする

パブリックノードを含むクラスタを作成する

Deployment マニフェストファイルを作成する

マニフェストファイルの例

プライベートノードを含むクラスタに Windows Server アプリケーションをデプロイする

プライベートノードを含むクラスタを作成する

Deployment マニフェストファイルを作成する

さまざまな Windows Server ノードイメージタイプでワークロードを使用する