Container Service for Kubernetes:ACK で ossfs 2.0 を使用して動的にプロビジョニングされた OSS ボリュームをマウントする

RRSA を活用することで、クラウドリソースへのアクセスに対して詳細な PV レベルの権限分離を実現でき、セキュリティリスクを大幅に低減できます。詳細については、「RRSA を使用して異なる Pod が異なるクラウドサービスにアクセスすることを承認する」をご参照ください。

前提条件

• Kubernetes 1.26 以降を実行している ACK クラスターが必要です。必要に応じて、クラスターを手動でアップグレードしてください。

• Container Storage Interface (CSI) プラグインのバージョンは 1.33.1 以降である必要があります。アップグレードするには、「csi-plugin と csi-provisioner のアップグレード」をご参照ください。

  1.30.4 より前のバージョンで RRSA を使用する場合は、「[製品の変更] CSI での ossfs のバージョンアップグレードとマウントプロセスの最適化」を参照して、RAM ロールの権限付与を設定してください。

• クラスターと同じ Alibaba Cloud アカウントに OSS バケットを作成済みであること。

  アカウントをまたいで OSS バケットをマウントするには、RRSA 認証方式を使用することをお勧めします。詳細については、「アカウントをまたいで OSS バケットをマウントする方法

ステップ 1: RAM ロールの作成

RRSA を使用してクラスターに OSS ボリュームをマウントしたことがある場合は、このステップをスキップしてください。初めての場合は、次の手順に従ってください。

1. ACK コンソールで RRSA 機能を有効にする。

2. OIDC IdP の RAM ロールを作成します。このロールは RRSA を使用して偽装されます。

   次の表に、サンプルロール demo-role-for-rrsa の主要なパラメーターを示します。

   パラメーター	説明
   ID プロバイダータイプ	[OIDC] を選択します。
   ID プロバイダー	クラスターに関連付けられているプロバイダー (例: ack-rrsa-<cluster_id>) を選択します。ここで、<cluster_id> は実際のクラスター ID です。
   条件	oidc:iss: デフォルト値のままにします。 oidc:aud: デフォルト値のままにします。 oidc:sub: 次の条件を手動で追加します。 キー: [oidc:sub] を選択します。 演算子: [StringEquals] を選択します。 値: system:serviceaccount:ack-csi-fuse:csi-fuse-ossfs を入力します。 この値では、ack-csi-fuse は ossfs クライアントが配置されている名前空間であり、カスタマイズできません。csi-fuse-ossfs はサービスアカウント名であり、必要に応じて変更できます。 サービスアカウント名の変更方法の詳細については、「RRSA 認証で指定された ARN または ServiceAccount を使用する方法
   ロール名	demo-role-for-rrsa を入力します。

ステップ 2: demo-role-for-rrsa ロールに権限を付与する

1. OSS アクセス用のカスタムポリシーを作成します。詳細については、「カスタムポリシーの作成」をご参照ください。

   要件に基づいて読み取り専用または読み取り/書き込みポリシーを選択し、mybucket をバケットの名前に置き換えます。

   • OSS 読み取り専用ポリシー

     OSS 読み取り専用ポリシードキュメントの表示

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

   • OSS 読み取り/書き込みポリシー

     OSS 読み取り/書き込みポリシードキュメントの表示

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

2. (オプション) KMS で管理されている CMK ID を使用して OSS オブジェクトを暗号化する場合は、RAM ユーザーに KMS 権限も設定する必要があります。詳細については、「暗号化操作」をご参照ください。

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

   説明

   信頼ポリシーを変更することで、OSS 権限が付与されている既存の RAM ロールを使用することもできます。詳細については、「既存の RAM ロールを使用して権限を付与する」をご参照ください。

ステップ 3: StorageClass の作成

動的に PV をプロビジョニングするためのテンプレートとして使用する StorageClass を作成します。

1. 次の内容で ossfs2-sc-rrsa.yaml という名前のファイルを作成します。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ossfs2-sc  # StorageClass の名前。
   parameters:
     bucket: cnfs-oss-test  # バケットの名前。
     path: /subpath  # マウントするサブディレクトリ。空のままにすると、ルートディレクトリがマウントされます。
     url: oss-cn-hangzhou-internal.aliyuncs.com  # OSS バケットが配置されているリージョンのエンドポイント。
     authType: rrsa
     roleName: demo-role-for-rrsa  # 先ほど作成した RAM ロール。
     fuseType: ossfs2
     volumeAs: sharepath
     otherOpts: "-o close_to_open=false"
   provisioner: ossplugin.csi.alibabacloud.com  # この値は固定です。
   reclaimPolicy: Retain  # 動的にプロビジョニングされた PV のリクレイムポリシー。Retain のみがサポートされており、PVC が削除されても PV と OSS バケット内のデータは削除されません。
   volumeBindingMode: Immediate  # ボリュームバインディングモード。OSS ボリュームはゾーンベースのノードアフィニティを必要としないため、デフォルト値の Immediate を使用できます。

   次の表に、parameters フィールドのパラメーターを示します。

   パラメーター	必須	説明
   bucket	はい	マウントする OSS バケットの名前。
   path	はい	バケット内のベースパス。volumeAs が sharepath に設定されている場合、動的にプロビジョニングされた各 PV には、このパスの下に /ack/<pv-name> などの一意のサブディレクトリが割り当てられます。
   url	はい	OSS バケットのアクセスエンドポイント。 クラスターノードとバケットが同じリージョンにある場合、または Virtual Private Cloud (VPC) 接続が確立されている場合は、内部エンドポイントを使用します。 マウントノードとバケットが異なるリージョンにある場合は、パブリックエンドポイントを使用します。 さまざまなアクセスエンドポイントの一般的なフォーマットは次のとおりです。 内部: http://oss-{{regionName}}-internal.aliyuncs.com または https://oss-{{regionName}}-internal.aliyuncs.com。 内部アクセスエンドポイントのフォーマット vpc100-oss-{{regionName}}.aliyuncs.com は非推奨です。できるだけ早く新しいフォーマットに切り替えてください。 パブリック: http://oss-{{regionName}}.aliyuncs.com または https://oss-{{regionName}}.aliyuncs.com。
   fuseType	はい	マウントに使用するクライアントを指定します。ossfs 2.0 クライアントを使用するには、ossfs2 に設定する必要があります。
   authType	はい	RRSA 認証方式が使用されることを宣言するには、rrsa に設定します。
   roleName	はい	作成または変更した RAM ロールの名前に設定します。 異なる PV に異なる権限を割り当てるには、権限セットごとに個別の RAM ロールを作成します。次に、各 PV の定義で roleName パラメーターを使用して、対応するロールに関連付けます。
   volumeAs	いいえ	PV がどのようにプロビジョニングされるかを定義します。sharepath は、各 PV が path で指定されたディレクトリに個別のサブディレクトリを作成することを示します。
   otherOpts	いいえ	OSS ボリュームに渡される追加のマウントオプションで、-o *** -o *** の形式でスペース区切りのフラグの文字列として指定します。例: -o close_to_open=false。 close-to-open オプションは、メタデータの一貫性を制御します。false (デフォルト) に設定すると、メタデータがキャッシュされ、小さなファイルの読み取りパフォーマンスが向上します。true に設定すると、クライアントはファイルが開かれるたびに GetObjectMeta リクエストを送信して OSS から最新のメタデータをフェッチし、待機時間と API 呼び出しの増加を犠牲にしてリアルタイムの一貫性を確保します。 その他のオプションパラメーターについては、「ossfs 2.0 マウントオプション」をご参照ください。

2. StorageClass を適用します。

   kubectl create -f ossfs2-sc-rrsa.yaml

3. StorageClass のステータスを確認します。

   kubectl get sc ossfs2-sc

   期待される出力:

   NAME        PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
   ossfs2-sc   ossplugin.csi.alibabacloud.com   Retain          Immediate                                  10s

ステップ 4: PVC の作成

ステップ 5: アプリケーションの作成とボリュームのマウント

ACK は、静的な AccessKey を Kubernetes Secret に保存することで、OSS ボリュームマウントの認証をサポートします。このアプローチは、特定のアプリケーションが長期的で固定されたアクセス権限を必要とするシナリオに適しています。

• PV によって参照される AccessKey が取り消されたり、その権限が変更されたりすると、ボリュームを使用しているアプリケーションはすぐにアクセスを失い、権限エラーが発生します。アクセスを復元するには、Secret 内の資格情報を更新し、アプリケーションの Pod を再起動して再マウントを強制します。このプロセスは短いサービス中断を引き起こすため、スケジュールされたメンテナンスウィンドウ中にのみ実行する必要があります。

• 手動でのキーローテーションに伴うダウンタイムを避けるために、代わりに RRSA 認証方式を使用することを強くお勧めします。

前提条件

• CSI V1.33.1 以降がインストールされた ACK クラスターが必要です。コンポーネントをアップグレードするには、「csi-plugin と csi-provisioner のアップグレード」をご参照ください。

• クラスターと同じ Alibaba Cloud アカウントに OSS バケットを作成済みであること。

  アカウントをまたいで OSS バケットをマウントするには、認証に RRSA を使用することをお勧めします。詳細については、「アカウントをまたいで OSS バケットをマウントする方法

ステップ 1: OSS アクセス権限を持つ RAM ユーザーを作成し、AccessKey ペアを取得する

kubectl create -n default secret generic oss-secret --from-literal='akId=xxxxxx' --from-literal='akSecret=xxxxxx'

ステップ 2: StorageClass の作成

1. 次の内容で ossfs2-sc.yaml という名前のファイルを作成します。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ossfs2-sc
   parameters:
     # 準備段階で作成した Secret を使用します。
     csi.storage.k8s.io/node-publish-secret-name: oss-secret  
     csi.storage.k8s.io/node-publish-secret-namespace: default
     fuseType: ossfs2
     bucket: cnfs-oss-test # バケットの名前。
     path: /subpath  # マウントするサブディレクトリ。空のままにすると、ルートディレクトリがマウントされます。
     url: oss-cn-hangzhou-internal.aliyuncs.com  # OSS バケットが配置されているリージョンのエンドポイント。
     otherOpts: "-o close_to_open=false"
   provisioner: ossplugin.csi.alibabacloud.com  # この値は固定です。
   reclaimPolicy: Retain  # 動的にプロビジョニングされた PV のリクレイムポリシー。Retain のみがサポートされており、PVC が削除されても PV と OSS バケット内のデータは削除されません。
   volumeBindingMode: Immediate  # ボリュームバインディングモード。OSS ボリュームはゾーンベースのノードアフィニティを必要としないため、デフォルト値の Immediate を使用できます。

   次の表に、parameters フィールドのパラメーターを示します。

   • Secret の構成

     パラメーター	必須	説明
     csi.storage.k8s.io/node-publish-secret-name	はい	AccessKey 情報を保存する Secret の名前。
     csi.storage.k8s.io/node-publish-secret-namespace	はい	AccessKey 情報を保存する Secret が配置されている名前空間。

   • ボリューム構成

     パラメーター	必須	説明
     fuseType	はい	マウントに使用するクライアントを指定します。ossfs 2.0 クライアントを使用するには、ossfs2 に設定する必要があります。
     bucket	はい	マウントする OSS バケットの名前。
     path	いいえ	OSS バケットのマウントパス。バケットのルートからの相対的なディレクトリ構造を表します。
     url	はい	OSS バケットをマウントするために使用されるエンドポイント。エンドポイントは、OSS コンソールのバケットの概要ページで確認できます。 ノードとバケットが同じリージョンにある場合、または VPC 接続が確立されている場合は、内部エンドポイントを使用します。 ノードとバケットが異なるリージョンにある場合は、パブリックエンドポイントを使用します。 さまざまなアクセスポートに一般的に使用されるフォーマットは次のとおりです。 内部エンドポイントフォーマット: http://oss-{{regionName}}-internal.aliyuncs.com または https://oss-{{regionName}}-internal.aliyuncs.com。 パブリックエンドポイントフォーマット: http://oss-{{regionName}}.aliyuncs.com または https://oss-{{regionName}}.aliyuncs.com。 重要 vpc100-oss-{{regionName}}.aliyuncs.com 内部エンドポイントフォーマットは非推奨です。すぐに新しいフォーマットに切り替えてください。
     otherOpts	いいえ	-o *** -o *** の形式で OSS ボリュームのカスタムパラメーターを入力します。例: -o close_to_open=false。 close-to-open: デフォルトでは無効になっています。有効にすると、ファイルが開かれるたびにシステムが GetObjectMeta リクエストを OSS に送信して最新のメタデータを取得します。これにより、メタデータが常に最新であることが保証されます。ただし、多数の小さなファイルを読み取るシナリオでは、頻繁なメタデータクエリによってアクセス待機時間が大幅に増加する可能性があります。 その他のオプションパラメーターについては、「ossfs 2.0 マウントオプション」をご参照ください。

2. StorageClass を作成します。

   kubectl create -f ossfs2-sc.yaml

ステップ 3: PVC の作成

ステップ 4: アプリケーションの作成とボリュームのマウント