Skip to main content
此產品有較新版本可以使用。
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

準備使用 ONTAP NAS 驅動程式設定後端

了解使用 ONTAP NAS 驅動程式配置 ONTAP 後端的要求、驗證選項和匯出原則。

從 25.10 版本開始,NetApp Trident 支援 "NetApp AFX 儲存系統"。NetApp AFX 儲存系統與其他 ONTAP 系統(ASA、AFF 和 FAS)在儲存層的實作方式上有所不同。

註 AFX 系統僅支援 ontap-nas 驅動程式(使用 NFS 協定);不支援 SMB 協定。

在 Trident 後端組態中、您無需指定系統為 AFX。當您選擇 `ontap-nas`作為 `storageDriverName`時、Trident 會自動偵測 AFX 系統。

需求

  • 對於所有 ONTAP 後端、 Trident 要求至少將一個 Aggregate 指派給 SVM 。

  • 您可以執行多個驅動程式,並建立指向其中一個或另一個驅動程式的儲存類別。例如,您可以設定使用 ontap-nas 驅動程式的 Gold 類別和使用 ontap-nas-economy 驅動程式的 Bronze 類別。

  • 所有 Kubernetes 工作節點都必須安裝適當的 NFS 工具。如需更多詳細資料,請參閱 "這裡"

  • Trident 僅支援掛載到在 Windows 節點上執行的 Pod 的 SMB 磁碟區。如需詳細資訊,請參閱 準備配置 SMB Volume

驗證 ONTAP 後端

Trident 提供兩種 ONTAP 後端驗證模式。

  • 基於憑證:此模式需要對 ONTAP 後端擁有足夠的權限。建議使用與預先定義安全登入角色關聯的帳戶,例如 admin`或 `vsadmin,以確保與 ONTAP 版本的最大相容性。

  • 基於憑證:此模式要求在後端安裝憑證,以便 Trident 與 ONTAP 叢集通訊。在這種情況下,後端定義必須包含用戶端憑證、金鑰以及受信任 CA 憑證(如果使用,建議使用)的 Base64 編碼值。

您可以更新現有後端,以在基於認證和基於憑證的方法之間移動。但是,一次只支援一種驗證方法。若要切換到不同的驗證方法,您必須從後端組態中移除現有方法。

警告 如果您嘗試同時提供憑證和憑證,則後端建立將會失敗,並出現錯誤,提示組態檔中提供了多個驗證方法。

啟用基於認證的驗證

Trident 需要 SVM 範圍 / 叢集範圍的管理員憑證才能與 ONTAP 後端通訊。建議使用標準預先定義的角色,例如 admin`或 `vsadmin。這可確保與未來 ONTAP 版本向前相容,因為未來版本可能會公開供 Trident 版本使用的功能 API。雖然可以建立自訂安全登入角色並將其與 Trident 搭配使用,但不建議這樣做。

後端定義範例如下所示:

YAML
---
version: 1
backendName: ExampleBackend
storageDriverName: ontap-nas
managementLIF: 10.0.0.1
dataLIF: 10.0.0.2
svm: svm_nfs
credentials:
  name: secret-backend-creds
JSON
{
  "version": 1,
  "backendName": "ExampleBackend",
  "storageDriverName": "ontap-nas",
  "managementLIF": "10.0.0.1",
  "dataLIF": "10.0.0.2",
  "svm": "svm_nfs",
  "credentials": {
        "name": "secret-backend-creds"
    }
}

請注意,後端定義是唯一以純文字形式儲存認證資料的地方。建立後端之後,使用者名稱/密碼會使用 Base64 編碼並儲存為 Kubernetes 機密。建立/更新後端是唯一需要知道認證資料的步驟。因此,這是僅限管理員的作業,由 Kubernetes/儲存管理員執行。

啟用基於憑證的驗證

新建和現有後端都可以使用憑證與 ONTAP 後端通訊。後端定義需要三個參數。

  • clientCertificate:用戶端憑證的 Base64 編碼值。

  • clientPrivateKey: 關聯私密金鑰的 Base64 編碼值。

  • trustedCACertificate:受信任 CA 憑證的 Base64 編碼值。如果使用受信任的 CA,則必須提供此參數。如果未使用受信任的 CA,則可以忽略此參數。

典型的工作流程包括以下步驟。

步驟
  1. 產生客戶端憑證和金鑰。產生時,將 Common Name(CN)設定為要進行驗證的 ONTAP 使用者。

    openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=vsadmin"
  2. 將信任的 CA 憑證新增至 ONTAP 叢集。儲存管理員可能已經處理此作業。如果未使用信任的 CA ,請忽略。

    security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name>
    ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
  3. 在 ONTAP 叢集上安裝用戶端憑證和金鑰(來自步驟 1)。

    security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name>
    security ssl modify -vserver <vserver-name> -client-enabled true
  4. 確認 ONTAP 安全登入角色支援 cert 驗證方法。

    security login create -user-or-group-name vsadmin -application ontapi -authentication-method cert -vserver <vserver-name>
    security login create -user-or-group-name vsadmin -application http -authentication-method cert -vserver <vserver-name>
  5. 使用產生的憑證測試驗證。將 <ONTAP Management LIF> 和 <vserver name> 替換為管理 LIF IP 和 SVM 名稱。您必須確保 LIF 的服務原則已設為 default-data-management

    curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
  6. 使用 Base64 對憑證、金鑰和受信任的 CA 憑證進行編碼。

    base64 -w 0 k8senv.pem >> cert_base64
    base64 -w 0 k8senv.key >> key_base64
    base64 -w 0 trustedca.pem >> trustedca_base64
  7. 使用上一步獲得的值建立後端。

    cat cert-backend-updated.json
    {
    "version": 1,
    "storageDriverName": "ontap-nas",
    "backendName": "NasBackend",
    "managementLIF": "1.2.3.4",
    "dataLIF": "1.2.3.8",
    "svm": "vserver_test",
    "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee",
    "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K",
    "storagePrefix": "myPrefix_"
    }
    
    #Update backend with tridentctl
    tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
    +------------+----------------+--------------------------------------+--------+---------+
    |    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
    +------------+----------------+--------------------------------------+--------+---------+
    | NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
    +------------+----------------+--------------------------------------+--------+---------+

更新驗證方法或輪換認證資料

您可以更新現有後端以使用不同的身份驗證方法或輪換其憑證。此操作雙向有效:使用使用者名稱/密碼的後端可以更新為使用憑證;使用憑證的後端可以更新為基於使用者名稱/密碼的身份驗證。為此、您必須移除現有的身份驗證方法並新增新的身份驗證方法。然後使用包含所需參數的更新後的 backend.json 檔案來執行 tridentctl update backend

cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"backendName": "NasBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}
#Update backend with tridentctl
tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
|    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
+------------+----------------+--------------------------------------+--------+---------+
註 輪換密碼時,儲存管理員必須先更新 ONTAP 上使用者的密碼。之後,後端需要進行更新。輪換證書時,可以為該使用者新增多個證書。後端隨後會更新以使用新證書,之後即可從 ONTAP 叢集中刪除舊證書。

更新後端不會中斷對已建立磁碟區的存取,也不會影響之後建立的磁碟區連線。後端更新成功表示 Trident 可以與 ONTAP 後端通訊並處理未來的磁碟區作業。

為 Trident 建立自訂 ONTAP 角色

您可以建立一個具有最低權限的 ONTAP 叢集角色,這樣您就不必使用 ONTAP 管理員角色在 Trident 中執行操作。當您在 Trident 後端組態中包含使用者名稱時,Trident 會使用您建立的 ONTAP 叢集角色來執行操作。

如需建立 Trident 自訂角色的詳細資訊,請參閱 "Trident 自訂角色產生器"

使用 ONTAP CLI
  1. 使用以下命令建立新角色:

    security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\>

  2. 為 Trident 使用者建立使用者名稱:

    security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description"

  3. 將角色對應至使用者:

    security login modify username <user_name\> –vserver <svm_name\> -role <role_name\> -application ontapi -application console -authmethod <password\>

使用 System Manager

在 ONTAP System Manager 中執行下列步驟:

  1. 建立自訂角色

    1. 若要在叢集層級建立自訂角色,請選取 Cluster > Settings

      (或)若要在 SVM 層級建立自訂角色、請選取 Storage > Storage VMs > required SVM> Settings > Users and Roles

    2. 選擇 Users and Roles 旁邊的箭頭圖示()。

    3. Roles 下選擇 +Add

    4. 定義角色規則,然後點選 Save

  2. 將角色對應到 Trident 使用者: + 在 Users and Roles 頁面上執行下列步驟:

    1. Users 下方選擇 Add 圖示 +

    2. 選擇所需的使用者名稱,然後在 Role 下拉式選單中選擇角色。

    3. 按一下 Save

如需更多資訊、請參閱下列頁面:

管理 NFS 匯出原則

Trident 使用 NFS 匯出原則來控制對其所配置之磁碟區的存取。

Trident 在處理匯出原則時提供兩種選項:

  • Trident 可以動態管理匯出策略;在這種模式下,儲存管理員指定 CIDR 區塊列表,這些 CIDR 區塊代表允許的 IP 位址。Trident 會在發佈時自動將落入這些範圍內的適用節點 IP 位址新增至匯出策略。或者,如果沒有指定 CIDR,則會將磁碟區發佈到的節點上找到的所有全域作用域單播 IP 位址新增至匯出策略。

  • 儲存管理員可以建立匯出原則並手動新增規則。除非在組態中指定不同的匯出原則名稱、否則 Trident 會使用預設的匯出原則。

動態管理匯出原則

Trident 提供了動態管理 ONTAP 後端匯出原則的功能。這使得儲存管理員能夠為工作節點 IP 指定允許的位址空間,而無需手動定義明確規則。這大大簡化了匯出原則的管理;對匯出原則的修改不再需要在儲存叢集上進行手動干預。此外,這還有助於將對儲存叢集的存取限制在僅掛載磁碟區且 IP 位址在指定範圍內的工作節點上,從而支援精細和自動化管理。

註 使用動態匯出策略時,請勿使用網路位址轉換(NAT)。啟用 NAT 後,儲存控制器看到的是前端 NAT 位址,而不是實際的 IP 主機位址,因此,如果在匯出規則中找不到符合項,則會拒絕存取。

範例

必須使用兩種組態選項。以下是後端定義範例:

---
version: 1
storageDriverName: ontap-nas-economy
backendName: ontap_nas_auto_export
managementLIF: 192.168.0.135
svm: svm1
username: vsadmin
password: password
autoExportCIDRs:
  - 192.168.0.0/24
autoExportPolicy: true
註 使用此功能時,必須確保 SVM 中的根接合點已預先建立匯出原則,且該原則包含允許節點 CIDR 區塊的匯出規則(例如預設匯出原則)。請務必遵循 NetApp 建議的最佳實務做法,為 Trident 專用 SVM。

以下以上述範例為例、說明此功能的工作原理:

  • autoExportPolicy 已設定為 true。這表示 Trident 會為使用此後端為 svm1 SVM 配置的每個磁碟區建立一個匯出策略,並使用 autoexportCIDRs 位址區塊處理規則的新增和刪除。在磁碟區連接到節點之前,該磁碟區使用一個空的匯出策略,其中沒有任何規則來防止對該磁碟區的未經授權的存取。當磁碟區發佈到節點時,Trident 會建立一個與底層 qtree 同名的匯出策略,該 qtree 包含指定 CIDR 區塊內的節點 IP 位址。這些 IP 位址也會加入到父 FlexVol 磁碟區使用的匯出策略中。

    • 例如:

      • 後端 UUID 403b5326-8482-40db-96d0-d83fb3f4daec

      • autoExportPolicy 設定為 true

      • 儲存前置詞 trident

      • PVC UUID a79bcf5f-7b6d-4a40-9876-e2551f159c1c

      • 名為 trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c 的 qtree 會為名為 `trident-403b5326-8482-40db96d0-d83fb3f4daec`的 FlexVol 建立匯出原則、為名為
        `trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c`的 qtree 建立匯出原則,並在 SVM 上建立名為 `trident_empty`的空白匯出原則。FlexVol 匯出原則的規則將是 qtree 匯出原則中所含任何規則的超集。未附加的磁碟區將重複使用空白匯出原則。

  • autoExportCIDRs 包含地址塊列表。此字段為可選字段,預設值為 ["0.0.0.0/0", "::/0"]。如果未定義,Trident 會新增在已發佈訊息的工作節點上找到的所有全域作用域單播位址。

在本例中,提供了 192.168.0.0/24 位址空間。這表示位於此位址範圍內且具有發佈的 Kubernetes 節點 IP 將新增至 Trident 建立的匯出原則。當 Trident 註冊其執行所在的節點時,會擷取該節點的 IP 位址,並根據 autoExportCIDRs 中提供的位址區塊進行檢查。在發佈時,篩選 IP 後,Trident 會為其發佈目標節點的用戶端 IP 建立匯出原則規則。

建立後端後,您可以更新其 autoExportPolicy`和 `autoExportCIDRs。您可以為自動管理的後端附加新的 CIDR 或刪除現有的 CIDR。刪除 CIDR 時請務必小心,以確保現有連線不會中斷。您也可以選擇停用後端的 autoExportPolicy,並回退到手動建立的匯出原則。這需要在後端組態中設定 `exportPolicy`參數。

Trident 建立或更新後端後、您可以使用 tridentctl`或對應的 `tridentbackend CRD 來檢查後端:

./tridentctl get backends ontap_nas_auto_export -n trident -o yaml
items:
- backendUUID: 403b5326-8482-40db-96d0-d83fb3f4daec
  config:
    aggregate: ""
    autoExportCIDRs:
    - 192.168.0.0/24
    autoExportPolicy: true
    backendName: ontap_nas_auto_export
    chapInitiatorSecret: ""
    chapTargetInitiatorSecret: ""
    chapTargetUsername: ""
    chapUsername: ""
    dataLIF: 192.168.0.135
    debug: false
    debugTraceFlags: null
    defaults:
      encryption: "false"
      exportPolicy: <automatic>
      fileSystemType: ext4

當節點被移除時、 Trident 會檢查所有匯出原則、以移除與該節點對應的存取規則。透過從受管理後端的匯出原則中移除此節點 IP 、 Trident 可防止惡意掛載、除非叢集中的新節點重複使用此 IP 。

對於先前存在的後端,使用 `tridentctl update backend`更新後端可確保 Trident 自動管理匯出原則。這會在需要時建立兩個新的匯出原則,分別以後端的 UUID 和 qtree 名稱命名。後端上的磁碟區在卸載並重新掛載後,將使用新建立的匯出原則。

註 刪除具有自動管理匯出原則的後端將刪除動態建立的匯出原則。如果重新建立該後端,則會將其視為新後端,並建立新的匯出原則。

如果正在執行中的節點的 IP 位址更新,您必須重新啟動該節點上的 Trident pod。Trident 隨後會更新其管理的後端匯出原則,以反映此 IP 位址變更。

準備配置 SMB Volume

稍加準備,即可使用 ontap-nas 驅動程式配置 SMB Volume 。

警告 您必須在 SVM 上同時設定 NFS 和 SMB/CIFS 通訊協定,才能為 ONTAP 內部部署叢集建立 ontap-nas-economy SMB Volume。若未設定其中任一通訊協定,將導致 SMB Volume 建立失敗。
註 autoExportPolicy 不支援 SMB 磁碟區。
開始之前

在配置 SMB 磁碟區之前、您必須具備以下條件。

  • Kubernetes 叢集包含一個 Linux 控制器節點和至少一個執行 Windows Server 2022 的 Windows 工作節點。Trident 僅支援掛載到在 Windows 節點上執行的 pod 的 SMB 磁碟區。

  • 至少需要一個包含您的 Active Directory 憑證的 Trident 金鑰。要產生金鑰 smbcreds

    kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'
  • CSI Proxy 設定為 Windows 服務。若要設定 csi-proxy,請參閱"GitHub:CSI Proxy""GitHub:適用於 Windows 的 CSI Proxy"以瞭解在 Windows 上執行的 Kubernetes 節點。

步驟
  1. 對於內部部署 ONTAP、您可以選擇性地建立 SMB 共用區、或 Trident 可以為您建立一個。

    註 Amazon FSx for ONTAP 需要 SMB 共用。

    您可以透過兩種方式建立 SMB 管理共用:使用 "Microsoft Management Console" 共用資料夾嵌入式管理單元或使用 ONTAP CLI。若要使用 ONTAP CLI 建立 SMB 共用:

    1. 如有必要、請建立共用區的目錄路徑結構。

      此 `vserver cifs share create`指令會檢查在建立共用時透過 -path 選項指定的路徑。如果指定的路徑不存在,則命令執行失敗。

    2. 建立與指定 SVM 相關聯的 SMB 共用:

      vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]
    3. 確認共用已建立:

      vserver cifs share show -share-name share_name
      註 詳情請參閱 "建立 SMB 共用區"
  2. 建立後端時,必須配置以下內容以指定 SMB 磁碟區。有關所有 FSx for ONTAP 後端設定選項,請參閱 "FSx for ONTAP 設定選項和範例"

    參數 說明 範例

    smbShare

    您可以指定以下選項之一:使用 Microsoft Management Console 或 ONTAP CLI 建立的 SMB 共用名稱;允許 Trident 建立 SMB 共用的名稱;或者您可以將此參數留空以封鎖對磁碟區的公共共用存取。對於內部部署 ONTAP,此參數為選用項目。對於 Amazon FSx for ONTAP 後端,此參數為必要項目且不能為空白。

    smb-share

    nasType

    * 必須設為 smb。*如果為 null ,則預設為 nfs

    smb

    securityStyle

    新磁碟區的安全樣式。對於 SMB 磁碟區,必須設定為 ntfs`或 `mixed

    ntfsmixed 適用於 SMB 磁碟區

    unixPermissions

    新磁碟區的模式。SMB 磁碟區必須保留空白。

    ""

啟用安全的 SMB

從 25.06 版本開始,NetApp Trident 支援使用 `ontap-nas`和 `ontap-nas-economy`後端建立的 SMB 磁碟區的安全性資源配置。啟用安全 SMB 後,您可以使用存取控制清單(ACL)為 Active Directory(AD)使用者和使用者群組提供對 SMB 共用的受控存取權限。

要記住的要點
  • 不支援匯入 `ontap-nas-economy`磁碟區。

  • ontap-nas-economy 磁碟區僅支援唯讀複本。

  • 如果啟用了安全 SMB,Trident 將忽略後端提到的 SMB 共用。

  • 更新 PVC 註解、儲存類別註解和後端欄位不會更新 SMB 共用 ACL。

  • 複製 PVC 註釋中指定的 SMB 共用 ACL 將優先於來源 PVC 中的 ACL 。

  • 啟用安全 SMB 時,請確保提供有效的 AD 使用者。無效使用者將不會被加入到 ACL 中。

  • 如果在後端、儲存類別和 PVC 中為同一個 AD 使用者提供不同的權限,則權限優先順序為:PVC、儲存類別,然後是後端。

  • 安全 SMB 支援 `ontap-nas`託管磁碟區匯入,但不適用於非託管磁碟區匯入。

步驟
  1. 請在 TridentBackendConfig 中指定 adAdminUser,如下例所示:

    apiVersion: trident.netapp.io/v1
    kind: TridentBackendConfig
    metadata:
      name: backend-tbc-ontap
      namespace: trident
    spec:
      version: 1
      storageDriverName: ontap-nas
      managementLIF: 10.193.176.x
      svm: svm0
      useREST: true
      defaults:
        adAdminUser: tridentADtest
      credentials:
        name: backend-tbc-ontap-invest-secret
  2. 在儲存類別中新增註解。

    trident.netapp.io/smbShareAdUser 註解新增至儲存類別,以啟用安全 SMB 而不會失敗。為註解 trident.netapp.io/smbShareAdUser 指定的使用者值應與 smbcreds 密鑰中指定的使用者名稱相同。您可以為 smbShareAdUserPermission 選擇下列其中一項: full_controlchangeread。預設權限為 full_control

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-smb-sc
  annotations:
    trident.netapp.io/smbShareAdUserPermission: change
    trident.netapp.io/smbShareAdUser: tridentADuser
parameters:
  backendType: ontap-nas
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: trident
  trident.netapp.io/nasType: smb
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
  1. 建立 PVC 。

    以下範例建立 PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc4
  namespace: trident
  annotations:
    trident.netapp.io/snapshotDirectory: "true"
    trident.netapp.io/smbShareAccessControl: |
      read:
        - tridentADtest
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ontap-smb-sc