Container Service for Kubernetes:静的にプロビジョニングされたOSSボリュームのマウント

使用上の注意

• OSSバケットは、動的にプロビジョニングされた永続ボリューム (PV) をサポートしません。 アカウント間でOSSバケットを使用しないことを推奨します。

• ACKクラスターが更新されると、kubeletが再起動されます。 その結果、ossfsが再起動され、マウントされたOSSディレクトリが使用できなくなります。 この場合、OSSボリュームがマウントされているポッドを再作成する必要があります。 YAMLファイルにヘルスチェック設定を追加して、ポッドを再起動し、OSSディレクトリが使用できなくなったときにOSSボリュームを再マウントできます。

  説明

  使用するcsi-pluginおよびcsi-provisionerコンポーネントがV1.18.8.45以降の場合、上記の問題は発生しません。

• アプリケーションテンプレートでsecurityContext.fsgroupパラメーターが指定されている場合、ボリュームのマウント後にkubeletがchmodまたはchown操作を実行するため、時間の消費が増加します。

  説明

  securityContext.fsgroupパラメーターを指定した場合のマウントプロセスを高速化する方法の詳細については、「OSSボリュームのマウントに長時間かかるのはなぜですか」をご参照ください。 「OSSボリュームに関するFAQ」トピックのセクション。

• ossfsを使用してList操作を実行すると、HTTPリクエストがOSSに送信され、リクエストされたファイルのメタデータが取得されます。 ディレクトリに100,000を超えるファイルなど、多数のファイルが含まれている場合、ossfsは大量のシステムメモリを占有します。 その結果、ポッド内でメモリ不足 (OOM) エラーが発生する可能性があります。 OOMエラーを引き起こす可能性のあるファイルの実際の数は、ノードメモリに関連しています。 この問題を解決するには、ディレクトリを分割するか、OSSバケット内のサブディレクトリをマウントします。

• ossfsは同時読み取りシナリオに適用できます。 同時読み取りシナリオでは、永続ボリュームクレーム (PVC) とPVのアクセスモードをReadOnlyManyに設定することを推奨します。 書き込み操作を処理するには、OSS SDKまたはossutilを使用して読み取りと書き込みを分割することを推奨します。 詳細については、「OSS読み書き分離のベストプラクティス」をご参照ください。

  説明

  ossfsを使用して、アクセスモードがReadWriteManyのOSSボリュームにデータを書き込む場合、次の項目に注意してください。

  • ossfsは、同時書き込み操作によって書き込まれたデータの一貫性を保証できません。

  • OSSボリュームがポッドにマウントされた後、ポッドまたはポッドのホストにログインし、マウントパス内のファイルを削除または変更すると、OSSバケット内のソースファイルも削除または変更されます。 重要なデータが誤って削除されないように、OSSバケットのバージョン管理を有効にすることができます。 詳細については、「バージョン管理」をご参照ください。

• サイズが10 MBを超えるファイルをOSSにアップロードする場合は、ファイルを複数のパーツに分割し、パーツを個別にアップロードできます。 マルチパートアップロードタスクが中断された場合にパーツに追加のストレージ料金が発生しないようにするには、次のいずれかの方法を使用して、不要になったパーツを削除します。

  • 手動でパーツを削除します。 詳細については、「パーツの削除」をご参照ください。

  • 部品を自動的に削除するライフサイクルルールを設定します。 詳細については、「最終変更時刻に基づくライフサイクルルール」をご参照ください。

RRSA認証を使用して静的にプロビジョニングされたOSSボリュームをマウントする

RRSA機能を使用して、ACKクラスターにデプロイされているさまざまなPVにアクセス制御を適用できます。 これにより、PVにきめ細かいAPI権限制御が実装され、セキュリティリスクが軽減されます。 詳細については、「RRSAを使用して異なるポッドに異なるクラウドサービスへのアクセスを許可する」をご参照ください。

(オプション) 手順1: RAMロールの作成

クラスターで初めてRRSA機能を使用する場合は、次の手順を実行します。 RRSA認証を使用してOSSボリュームをクラスターにマウントした場合は、この手順をスキップしてください。

1. ACKコンソールにログインし、RRSAを有効にします。 詳細については、「RRSAを使用して異なるポッドに異なるクラウドサービスへのアクセスを許可する」をご参照ください。

2. RRSA認証を使用してOSSボリュームをマウントするためのRAMロールを作成します。 RAMロールは、RRSAを使用してOSSボリュームをマウントするときにクラスターによって引き受けられます。

   RAMロールを作成するときに、[信頼できるエンティティの選択] パラメーターとして [IdP] を選択します。 この例では、RAMロールの名前はdemo-role-for-rrsaです。

   1. にログインします。RAMコンソールをAlibaba Cloudアカウントに置き換えます。

   2. 左側のナビゲーションウィンドウで、[ID] > [ロール] を選択します。 [ロール] ページで、[ロールの作成] をクリックします。

   3. では、ロールの作成パネル、選択IdP[信頼できるエンティティ] を選択し、次へ.

   4. では、ロールの設定ステップ、パラメータを設定し、OK.

      この例で設定されているパラメーターを次の表に示します。

      パラメーター	説明
      RAMロール名	RAM ロールの名前です。 この例では、demo-role-for-rrsaが使用されています。
      注	必要に応じて、 RAM ロールの説明です。
      IdPタイプ	IDプロバイダー (IdP) のタイプ。 [OIDC] を選択します。
      IdPの選択	使用するIdP。 ack-rrsa-<cluster_id> 形式の値を選択します。 <cluster_id> は、クラスターのIDを示します。
      条件	oidc:iss: デフォルト値を使用します。 oidc:aud: sts.aliyuncs.comを選択します。 oidc:sub: 条件演算子をStringEqualsに設定します。 この例では、system:serviceaccount:ack-csi-fuse:csi-fuse-ossfsが使用されています。

手順2: demo-role-for-rrsaロールに権限を付与

1. 次のカスタムポリシーを作成して、RAMユーザーにOSS権限を付与します。 詳細については、「カスタムポリシーの作成」をご参照ください。

   次のポリシーのmybucketをOSSバケットの名前に置き換えます。

   • OSSで読み取り専用権限を付与するポリシー

     ポリシードキュメント

     {
         "Statement": [
             {
                 "Action": [
                     "oss:Get*",
                     "oss:List*"
                 ],
                 "Effect": "Allow",
                 "Resource": [
                     "acs:oss:*:*:mybucket",
                     "acs:oss:*:*:mybucket/*"
                 ],
             }
         ],
         "Version": "1"
     }

   • OSSの読み取りおよび書き込み権限を付与するポリシー

     ポリシードキュメント

     {
         "Statement": [
             {
                 "Action": "oss:*",
                 "Effect": "Allow",
                 "Resource": [
                     "acs:oss:*:*:mybucket",
                     "acs:oss:*:*:mybucket/*"
                 ],
             }
         ],
         "Version": "1"
     }

2. 必要に応じて、 OSSバケット内のファイルがkey Management Service (KMS) でカスタマーマスターキー (CMK) を使用して暗号化されている場合、RAMユーザーにKMS権限を付与する必要があります。 詳細については、「OSSボリュームの暗号化」トピックのOSSボリュームの暗号化セクションをご参照ください。

3. demo-role-for-rrsaロールに必要な権限を付与します。 詳細については、「RAMロールへの権限の付与」をご参照ください。

   説明

   既存のRAMロールを使用する場合は、必要なOSS権限が付与されているRAMロールの信頼ポリシーを変更できます。 詳細については、「RRSAを使用して異なるポッドに異なるクラウドサービスへのアクセスを許可する」トピックの「既存のRAMロールを使用してRAMロールに必要な権限を付与する」セクションをご参照ください。

ステップ3: PVとPVCの作成

1. RRSA認証を使用するPVを作成します。

   1. 次のサンプルテンプレートを使用して、pv-rrsa.yamlという名前のPV構成ファイルを作成します。 このファイルでは、RRSA認証が有効になっています。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: pv-oss
        labels:    
          alicloud-pvname: pv-oss
      spec:
        capacity:
          storage: 5Gi
        accessModes:
          - ReadOnlyMany
        persistentVolumeReclaimPolicy: Retain
        csi:
          driver: ossplugin.csi.alibabacloud.com
          volumeHandle: pv-oss # Specify the name of the PV. 
          volumeAttributes:
            bucket: "oss"
            url: "oss-cn-hangzhou.aliyuncs.com"
            otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other"
            authType: "rrsa"
            roleName: "demo-role-for-rrsa"

      パラメーター	説明
      name	PV の名前。
      labels	PVに追加されるラベル。
      ストレージ	OSSバケットの使用可能なストレージ。
      accessModes	アクセスモード。 有効な値: ReadOnlyManyとReadWriteMany。 ReadOnlyManyを選択した場合、ossfsはOSSバケットを読み取り専用モードでマウントします。
      persistentVolumeReclaimPolicy	PVの再利用ポリシー。 OSSボリュームは保持ポリシーのみをサポートしています。 つまり、PVCが削除されると、PVもOSSバケット内のデータも削除されません。
      ドライバー	ドライバーのタイプ。 この例では、パラメーターはossplugin.csi.alibabacloud.comに設定されています。 これは、OSS CSIコンポーネントが使用されることを示します。
      volumeHandle	PV の名前。
      バケット	マウントするOSSバケット。
      url	マウントするOSSバケットのエンドポイント。 ノードとOSSバケットが同じリージョンにある場合、または仮想プライベートクラウド (VPC) を介して接続されている場合は、OSSバケットの内部エンドポイントを使用します。 ノードとOSSバケットが異なるリージョンにある場合は、OSSバケットのパブリックエンドポイントを使用します。 エンドポイント形式: 内部エンドポイント: http:// oss-{{regionName}}-internal.aliyuncs.comまたはhttps:// oss-{{regionName}}-internal.aliyuncs.com パブリックエンドポイント: http:// oss-{{regionName}}.aliyuncs.comまたはhttps:// oss-{{regionName}}.aliyuncs.com 重要 実際のエンドポイントは、OSSコンソールの [概要] ページに表示されます。 vpc100-oss-{{regionName}}.aliyuncs.comの内部アクセスポートは非推奨です。 それに応じて設定を更新してください。
      otherOpts	OSSボリュームに -o *** -o *** 形式のカスタムパラメーターを設定できます。 例: -o umask=022 -o max_stat_cache_size=0 -o allow_other umask: ossfs内のファイルの権限マスクを変更します。 たとえば、umask=022を指定した場合、ossfsのファイルのアクセス許可マスクは755に変わります。 デフォルトでは、OSS SDKまたはコンソールを使用してアップロードされたファイルの権限マスクはossfsで640されます。 したがって、読み取りと書き込みを分割する場合は、umaskパラメーターを指定することを推奨します。 max_stat_cache_size: メタデータをキャッシュできるファイルの最大数。 メタデータキャッシュはls操作を高速化できます。 ただし、OSS SDK、コンソール、ossutilなどのメソッドを使用してファイルを変更した場合、ファイルのキャッシュされたメタデータは同期的に更新されません。 その結果、キャッシュされたメタデータが古くなり、ls操作の結果が不正確になる可能性があります。 allow_other: 他のユーザーがマウントされたディレクトリにアクセスできるようにします。 ただし、これらのユーザーはディレクトリ内のファイルにアクセスできません。 その他のパラメーターの詳細については、「ossfsでサポートされているオプション」をご参照ください。
      パス	マウントするOSSバケットのルートディレクトリからの相対パス。 デフォルト値: /。 このパラメーターは、V1.14.8.32-c77e277b-aliyun以降のcsi-pluginでサポートされています。 1.91より前のossfsバージョンの場合は、事前にOSSでこのパスを作成する必要があります。 詳細については、「ossfs 1.91以降の機能およびossfsパフォーマンスベンチマーク」をご参照ください。
      authType	認証方法。 このパラメーターをrrsaに設定します。これは、RRSA認証が使用されていることを示します。
      roleName	使用するRAMロールの名前。 このパラメーターを、手順1で作成または変更したRAMロールの名前に設定します。 異なるPVに対して異なる権限を設定する必要がある場合は、複数のRAMロールを作成し、roleNameパラメーターでRAMロールを指定できます。

      説明

      RRSA認証で指定されたAlibaba Cloudリソース名 (ARN) またはServiceAccountsを使用する方法の詳細については、RRSA認証で指定されたARNまたはServiceAccountを使用するにはどうすればよいですか。 「OSSボリュームに関するFAQ」トピックのセクション。

   2. 次のコマンドを実行して、RRSA認証を使用するPVを作成します。

      kubectl create -f pv-rrsa.yaml

2. 次のコマンドを実行して、静的にプロビジョニングされたPVCを作成します。

   kubectl create -f pvc-oss.yaml

   静的にプロビジョニングされたpvcを作成するには、次のPVC-oss.yamlサンプルファイルを使用します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-oss
   spec:
     accessModes:
       - ReadOnlyMany
     resources:
       requests:
         storage: 5Gi
     selector:
       matchLabels:
         alicloud-pvname: pv-oss

   パラメーター	説明
   name	PVCの名前。
   accessModes	アクセスモード。 有効な値: ReadOnlyManyとReadWriteMany。 ReadOnlyManyを選択した場合、ossfsはOSSバケットを読み取り専用モードでマウントします。
   ストレージ	PVCが主張する容量。 請求される容量は、PVCに結合されるPVの容量を超えることはできない。
   alicloud-pvname	PVを選択してPVCにバインドするために使用されるラベル。 ラベルは、PVCに結合されるPVのラベルと同じでなければなりません。

   左側のナビゲーションウィンドウで、[ボリューム] > [ボリューム要求] を選択します。 [永続的なボリューム要求] ページで、作成されたPVCを見つけることができます。

ステップ4: アプリケーションの作成

oss-staticという名前のアプリケーションを作成し、PVをアプリケーションにマウントします。

次のコマンドを実行して、oss-static.yamlという名前のファイルを作成します。

kubectl create -f oss-static.yaml

次のoss-static.yamlサンプルファイルを使用して、アプリケーションを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oss-static
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
          - name: pvc-oss
            mountPath: "/data1"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

• livenessProbe: ヘルスチェックの設定。 詳細は、「OSSボリューム」をご参照ください。

• mountPath: OSSバケットがコンテナーにマウントされるパス。

• claimName: アプリケーションが使用するPVCの名前。

AccessKey認証を使用して、静的にプロビジョニングされたOSSボリュームをRAMユーザーとしてマウントします

kubectl create -f oss-static.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oss-static
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
          - name: pvc-oss
            mountPath: "/data1"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

OSSボリュームがデータを保持および共有できるかどうかを確認する

1. を実行するポッドを表示します。oss-staticアプリケーションとOSSバケット内のファイル。

   1. 次のコマンドを実行して、oss-staticアプリケーションを実行するポッドを照会します。

      kubectl get pod

      期待される出力:

      NAME                             READY   STATUS    RESTARTS   AGE
      oss-static-66fbb85b67-d****      1/1     Running   0          1h
      oss-static-66fbb85b67-l****      1/1     Running   0          1h

   2. tmpfileファイルを作成します。

      • OSSボリュームがReadWriteManyモードでマウントされている場合は、次のコマンドを実行して、/dataパスにtmpfileファイルを作成します。

        kubectl exec oss-static-66fbb85b67-d**** -- touch /data/tmpfile
        kubectl exec oss-static-66fbb85b67-l**** -- touch /data/tmpfile

      • OSSボリュームがReadOnlyManyモードでマウントされている場合は、OSSコンソールまたはcpコマンド (アップロードオブジェクト) を使用して、OSSバケットの対応するパスにtmpfileファイルをアップロードします。

2. 次のコマンドを実行して、oss-static-66fbb85b67-d **** ポッドの /dataパスのファイルとoss-static-66fbb85b67-l **** ポッドの /data1パスのファイルを照会します。

   kubectl exec oss-static-66fbb85b67-d**** -- ls /data | grep tmpfile
   kubectl exec oss-static-66fbb85b67-l**** -- ls /data1 | grep tmpfile

   期待される出力:

   tmpfile

   出力は、ファイルが両方のポッドに存在することを示します。 つまり、ポッドはOSSボリュームに保存されているデータを共有します。

   説明

   出力が返されない場合は、CSIコンポーネントのバージョンが1.20.7以降であるかどうかを確認します。 詳細については、「csi-plugin」をご参照ください。

3. 次のコマンドを実行して、oss-static-66fbb85b67-d **** ポッドを削除します。

   kubectl delete pod oss-static-66fbb85b67-d****

   期待される出力:

   pod "oss-static-66fbb85b67-d****" deleted

4. ポッドの削除後もファイルが存在することを確認します。

   1. 次のコマンドを実行して、再作成されたポッドを照会します。

      kubectl get pod

      期待される出力:

      NAME                             READY   STATUS    RESTARTS   AGE
      oss-static-66fbb85b67-l****      1/1     Running   0          1h
      oss-static-66fbb85b67-z****      1/1     Running   0          40s

   2. 次のコマンドを実行して、ポッドの /dataパス内のファイルを照会します。

      kubectl exec oss-static-66fbb85b67-z**** -- ls /data | grep tmpfile

      期待される出力:

      tmpfile

      出力は、temfileファイルがまだ存在することを示します。 これは、OSSボリュームがデータを保持できることを意味します。