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


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

Windows Server アプリケーションを標準クラスタにデプロイする

Windows Server アプリケーションをデプロイする手順は次のとおりです。

  1. クラスタを作成する。
  2. Deployment マニフェスト ファイルを作成する。
  3. Deployment を作成して公開する。
  4. Pod が実行されていることを確認する。

クラスタの作成

手順については、Windows Server ノードプールを使用してクラスタを作成するをご覧ください。

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

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

これにより、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 として作成して公開します。

  1. Deployment を作成するには、次のコマンドを実行します。

    kubectl apply -f iis.yaml
    
  2. Deployment を公開するには、次のコマンドを実行します。

    kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
    

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

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

  1. kubectl を使用して、Pod のステータスを確認します。

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

    NAME                   READY     STATUS    RESTARTS   AGE
    iis-5c997657fb-w95dl   1/1       Running   0          28s
    
  3. Service のステータスを取得して、外部 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 アプリケーションを限定公開クラスタにデプロイする

このセクションでは、Windows Server コンテナ アプリケーションを限定公開クラスタにデプロイする方法を説明します。

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

限定公開クラスタを使用するには、非分散レイヤを限定公開レジストリに push できるように Docker デーモンを構成します。詳細については、Docker の GitHub ページの Considerations for air-gapped registries をご覧ください。

Windows Server アプリケーションを限定公開クラスタにデプロイするには:

  1. Windows Server ノードを含めた限定公開クラスタを作成する。
  2. Windows Server アプリケーションの Docker イメージをビルドする。
  3. アプリケーションを限定公開クラスタにデプロイする。
  4. Pod が動作していることを確認する。

限定公開クラスタを作成する

Windows Server ノードを含めたクラスタの作成限定公開クラスタの作成の手順を行い、Windows ノードプールを作成して限定公開クラスタに追加します。

限定公開クラスタで使用する Windows Server アプリケーションイメージを作成する

  1. Docker イメージをビルドするには、アプリケーション コンテナを実行する Windows Server バージョン(Windows Server 2019、Windows Server バージョン 1909 など)で Compute Engine インスタンスを起動します。また、インターネットに接続されていることを確認します。

  2. Compute インスタンスで、Docker デーモン config に移動します。

    PS C:\> cat C:\ProgramData\docker\config\daemon.json
    
  3. これらのラインを追加して、外部レイヤを限定公開レジストリに push できるように Docker daemon.json ファイルを構成します。

    {
      "allow-nondistributable-artifacts": ["gcr.io"]
    }
    

    gcr.io は、イメージがホストされる Container Registry を表します。

  4. Docker デーモンを再起動します。

    PS C:\> Restart-Service docker
    
  5. アプリケーションの Docker イメージをビルドしてタグを付けします。

    PS C:\> cd C:\my-app
    
    PS C:\my-app> docker build -t gcr.io/my-project/my-app:v2 .
    

    このコマンドを実行すると、Docker は現在のディレクトリにある Dockerfile を使用してイメージをビルドし、gcr.io/my-project/my-app:v2 などの名前を使用してタグ付けします。

  6. アプリケーションの Docker イメージを my-projectgcr.io レジストリに push します。allow-nondistributable-artifacts 構成を設定すると、Windows 基本レイヤが限定公開レジストリに push されます。

    PS C:\my-app> docker push gcr.io/my-project/my-app:v2
    

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

my-app.yaml という名前のサンプル Deployment マニフェスト ファイルを以下に示します。この例のイメージは、前のステップ(gcr.io/my- project/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: gcr.io/my-project/my-app:v2

このアプリケーションを限定公開クラスタにデプロイするには:

gcloud container clusters get-credentials var>private-cluster-name
kubectl apply -f my-app.yaml

ここで、private-cluster-name は作成したクラスタの名前です。

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

すべての Pod を一覧表示して、正しく実行されていることを確認します。

kubectl get pods

予想される結果には、ステータスが Running の Pod が表示されます。

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 イメージタイプ(LTSC または SAC)を使用して、ノードプールをクラスタに追加できます。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 または 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 ノードにスケジュールされるのを防ぐことができます。