SMB CSI ドライバを使用して Windows Server ノードの SMB ボリュームにアクセスする

標準

---

このページでは、オープンソースの Kubernetes 用 SMB CSI ドライバを使用して、Windows サーバーノードがある Google Kubernetes Engine（GKE）クラスタで NetApp Cloud Volumes Service の SMB ボリュームにアクセスする方法の例を示します。

注: オープンソースの Kubernetes 用 SMB CSI ドライバを使用して、Linux ノードのある Google Kubernetes Engine（GKE）クラスタ（Container-Optimized OS の場合は GKE バージョン 1.20 以降、Ubuntu の場合はバージョン 1.19 以降）で NetApp Cloud Volumes Service SMB ボリュームにアクセスすることもできます。

概要

Server Message Block（SMB）プロトコルは、Microsoft Windows で使用されているネットワーク ファイル共有プロトコルです。Windows Server ノードプールを使用する GKE クラスタで SMB を使用するには、オープンソースの Kubernetes 用 SMB CSI ドライバを使用します。

タスク

以降のセクションでは、Windows Server ノードがある GKE クラスタで NetApp Cloud Volumes Service の SMB ボリュームにアクセスする方法の例を示します。この例では、オープンソースの Kubernetes 用 SMB CSI ドライバを使用します。

注: オープンソースの Kubernetes 用 SMB CSI ドライバのサポートは、ベスト エフォート ベースで提供され、GKE SLA は適用されません。

Active Directory をデプロイする

このタスクでは、Active Directory を作成します。Active Directory がすでにある場合は、この作業をスキップできます。

セルフマネージド Active Directory をデプロイするため、次の手順では、Google Cloud Marketplace ソリューションを使用して、2 つの Active Directory ドメイン コントローラを持つ新しい Active Directory ドメインを作成します。

1. Google Cloud コンソールの Cloud Marketplace で、Microsoft Active Directory のページに移動します。
2. [運用開始] をクリックします。
3. デプロイ構成を完了します。DNS サーバーが NetApp Cloud Volumes Service SMB ボリュームと同じリージョンにあることを確認します。利用可能なリージョンを確認します。
4. [デプロイ] をクリックします。

代わりに Managed Service for Microsoft Active Directory（Managed Microsoft AD）を使用する場合は、次の操作を行います。

1. Managed Microsoft AD ドメインを作成します。
2. ドメインと NetApp Cloud Volumes Service ネットワーク間にドメイン ピアリングを構成します。
3. Active Directory 関連のタスクを実行するには、ドメインに接続します。

限定公開 DNS 転送ゾーンを作成する

DNS クエリを Active Directory ドメイン コントローラに転送する限定公開 DNS 転送ゾーンを作成します。

ファイアウォール ルールを更新する

Cloud DNS からのクエリが AD 接続に到達できるようにするには、AD のファイアウォール ルールで、ソースフィルタにソース IP 範囲として 35.199.192.0/19 を追加します。

詳細については、Cloud Volumes Service の SMB アクセスに関するセキュリティの考慮事項をご覧ください。

Cloud Volumes Service への Active Directory 接続を作成する

手順については、AD 接続の作成をご覧ください。

Cloud Volumes Service に SMB ボリュームを作成する

手順については、SMB ボリュームの作成をご覧ください。

PersistentVolume または StorageClass の source 値として、新しい SMB ボリュームのマウント ターゲットを次の形式で使用します。

"//SMB_SERVER_NAME/SHARE_NAME"

マウント ターゲットと手順は、Cloud Volumes Service のボリューム一覧ページと個々のボリュームの詳細ページで確認できます。

注: CSI プロキシ コンポーネントは、GKE クラスタ バージョン 1.19 以降で使用できます。

AD ドメインに参加済みのノードを持つクラスタを作成する

Windows Server ノードが自動的に Active Directory ドメインに参加するように構成するの手順を行います。

SMB CSI ドライバをインストールする

1. Kubernetes 用オープンソース SMB CSI ドライバをインストールします。

2. Pod から SMB ボリュームにアクセスするには、ユーザー名とパスワードをエンコードする Secret を作成します。

   kubectl create secret generic SECRET_NAME \
       --from-literal username="USERNAME" \
       --from-literal password="PASSWORD"
   

   次のように置き換えます。

   • SECRET_NAME: Secret の名前。
   • USERNAME: ユーザー名。Secret 内にエンコードされるユーザー名には、domain\$username という形式のドメイン名を含める必要があります。SMB 共有がドメインの一部でない場合、ドメインには任意の文字列を使用できます。
   • PASSWORD: ユーザーのパスワード。

SMB ボリュームにアクセスする

SMB のボリュームにアクセスするには、次のいずれかを選択できます。

• StorageClass
• PersistentVolume

警告: Kubernetes 用オープンソース SMB CSI ドライバでは、PersistentVolume や StorageClass の Delete 再利用ポリシーはサポートされていません。

StorageClass を使用して SMB ボリュームにアクセスする

StorageClass を使用して SMB ボリュームにアクセスするには、次の操作を行います。

1. StorageClass を作成します。以下に、sc-smb.yaml という名前のマニフェスト ファイルを示します。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: smb
   provisioner: smb.csi.k8s.io
   parameters:
     source: "//SMB_SERVER_NAME/SHARE_NAME"
     csi.storage.k8s.io/node-stage-secret-name: "SECRET_NAME"
     csi.storage.k8s.io/node-stage-secret-namespace: "default"
     createSubDir: "false"    # optional: create a sub dir for new volume
   reclaimPolicy: Retain      # only Retain is supported
   volumeBindingMode: Immediate
   mountOptions:
     - dir_mode=0777
     - file_mode=0777
     - uid=1001
     - gid=1001
   

   この例では、mountOptions フィールドを使用しています。これは、Windows Server では省略可能ですが、使用すると、Linux と Windows Server の両方でこの StorageClass が機能します。

   次のように置き換えます。

   • SMB_SERVER_NAME: ドメインを含む SMB サーバーのホスト名。たとえば、マウントパス //adserver-faab.cvssmb.com/eager-hungry-skossi のホスト名は adserver-faab.cvssmb.com です。
   • SHARE_NAME: SMB 共有の名前。たとえば、マウントパス //adserver-faab.cvssmb.com/eager-hungry-skossi の共有名は eager-hungry-skossi です。ルート共有は SMB 共有でのみ使用してください。詳細については、関連する既知の問題をご覧ください。
   • SECRET_NAME: SMB ボリュームにアクセスするための認証情報を含む Secret の名前。

2. マニフェスト ファイルに基づいて StorageClass リソースを作成します。

   kubectl create -f sc-smb.yaml
   

3. StorageClass を使用する Pod をデプロイします。以下に、statefulset-smb.yaml という名前のマニフェスト ファイルを示します。この StatefulSet にデプロイされた Pod は、マウントされた SMB ドライブに data.txt ファイルを作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: busybox
     labels:
       app: busybox
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: busybox
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-smb
     labels:
       app: busybox
   spec:
     serviceName: statefulset-smb
     replicas: 1
     template:
       metadata:
         labels:
           app: busybox
       spec:
         nodeSelector:
           "kubernetes.io/os": windows
         containers:
           - name: statefulset-smb
             image: e2eteam/busybox:1.29
             command:
               - "powershell.exe"
               - "-Command"
               - "while (1) { Add-Content -Encoding Ascii C:\\sc\\smb\\data.txt $(Get-Date -Format u); sleep 1 }"
             volumeMounts:
               - name: smb
                 mountPath: "/sc/smb"
         tolerations:
           - key: "node.kubernetes.io/os"
             operator: "Exists"
             effect: "NoSchedule"
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: busybox
     volumeClaimTemplates:
       - metadata:
           name: smb
           annotations:
             volume.beta.kubernetes.io/storage-class: smb
         spec:
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 10Gi
   

4. マニフェスト ファイルに基づいて StatefulSet リソースを作成します。

   kubectl create -f statefulset-smb.yaml
   

PersistentVolume と PersistentVolumeClaim を使用してボリュームにアクセスする

PersistentVolume と PersistentVolumeClaim を使用して SMB ボリュームにアクセスするには、次の操作を行います。

1. PersistentVolume を作成します。以下に、pv-smb.yaml という名前のマニフェスト ファイルを示します。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-smb
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     mountOptions:
       - dir_mode=0777
       - file_mode=0777
       - vers=3.0
     csi:
       driver: smb.csi.k8s.io
       readOnly: false
       volumeHandle: VOLUME_ID
       volumeAttributes:
         source: "//SMB_SERVER_NAME/SHARE_NAME"
       nodeStageSecretRef:
         name: SECRET_NAME
         namespace: default
   

   この例では、mountOptions フィールドを使用しています。これは、Windows Server では省略可能ですが、使用すると、Linux と Windows Server の両方でこの PersistentVolume が機能します。

   次のように置き換えます。

   • VOLUME_ID: ボリュームの一意の ID。
   • SMB_SERVER_NAME: ドメインを含む SMB サーバーのホスト名。
   • SHARE_NAME: SMB 共有の名前。
   • SECRET_NAME: SMB ボリュームにアクセスするための認証情報を含む Secret の名前。

2. マニフェスト ファイルに基づいて PersistentVolume リソースを作成します。

   kubectl create -f pv-smb.yaml
   

3. PersistentVolumeClaim を作成します。以下に、pvc-smb.yaml という名前のマニフェスト ファイルを示します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-smb
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     volumeName: pv-smb
     storageClassName: ""
   

4. マニフェスト ファイルに基づいて PersistentVolumeClaim リソースを作成します。

   kubectl create -f pvc-smb.yaml
   

5. PersistentVolumeClaim を使用する Pod をデプロイします。以下に、busybox-smb.yaml という名前のマニフェスト ファイルを示します。これは、pvc-smb を使用する Pod のデプロイ用に使用されます。このデプロイでは、マウントされた SMB ドライブに data.txt ファイルが作成されます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: busybox-smb
     labels:
       app: busybox
   spec:
     replicas: 1
     template:
       metadata:
         name: busybox
         labels:
           app: busybox
       spec:
         nodeSelector:
           "kubernetes.io/os": windows
         containers:
           - name: busybox
             image: e2eteam/busybox:1.29
             command:
               - "powershell.exe"
               - "-Command"
               - "while (1) { Add-Content -Encoding Ascii C:\\pv\\pv-smb\\data.txt $(Get-Date -Format u); sleep 1 }"
             volumeMounts:
               - name: smb
                 mountPath: "/pv/pv-smb"
         tolerations:
           - key: "node.kubernetes.io/os"
             operator: "Exists"
             effect: "NoSchedule"
         volumes:
           - name: smb
             persistentVolumeClaim:
               claimName: pvc-smb
     selector:
       matchLabels:
         app: busybox
   

6. マニフェスト ファイルから Deployment を作成します。

   kubectl apply -f  busybox-smb.yaml
   

SMB ボリュームへのアクセスをテストする

SMB ボリュームで data.txt ファイルにアクセスできることを確認するには、次のどちらかを行います。

• コンテナで PowerShell セッションを開始し、data.txt ファイルをリスト表示します。

  kubectl exec POD_NAME -- powershell.exe -c "ls PATH_TO_THE_FILE"
  

• 別の VM で SMB ドライブを開き、data.txt ファイルがリモート共有で正常に作成されたことを確認します。

既知の問題

再起動後の Windows でのマウントエラー

問題: たとえば、\\smb-server\share\test1 がすでにマウントされている場合、Windows ノードが再起動した後にボリューム \\smb-server\share\test2 をマウントするときにエラーが発生する可能性があります。

理由: StorageClass と PersistentVolume の source フィールドは、1 つのクラスタ内の 1 つの SMB サーバーに対してのみルート共有を使用する必要があります。また、デプロイでは volumeMounts.subPath プロパティを使用する必要があります。

回避策: source として \\smb-server\share のみを使用します。

他の既知の問題については、Kubernetes 用のオープンソース SMB CSI ドライバの既知の問題のページをご覧ください。

次のステップ

• Windows アプリケーションをデプロイする方法を学習する。
• NetApp Cloud Volumes Service について学習する。