為什么要提出在ACK集群上實現Slurm HPC & Kubernetes負載混合調度呢？

• 原因分析：目前ACK會提供靜態分配+分離調度的方案，但是由于每個Slurm Pod的規格固定，且Slurm Pod屬于提前占用集群資源，Slurm集群中資源空閑時Kubernetes無法使用這些已占用的集群資源，從而導致集群資源碎片。此外，修改Slurm Pod的資源規格需要刪除Pod重建，因此在Slurm與Kubernetes資源占用變化較大的場景中，節點遷移的難度較大。

• 改進方案：考慮到現有方案的弊端，ACK Slurm Operator提供一種Slurm & Kubernetes混合調度方案，通過配置運行在Kubernetes集群中的協調器以及Slurm集群的擴展資源插件，使得Kubernetes與Slurm可以共享集群資源，并且避免在分配資源時出現重復分配的情況。

目前任務共享資源方案可以分為以下兩種。

靜態分配 + 分離調度	Slurm HPC + Kubernetes負載混合調度

Slurm HPC + Kubernetes負載混合調度方案的運行原理如下圖所示。

1.1 安裝ack-slurm-operator組件

確認已安裝的ACK集群版本為v1.26及以上。具體操作，請參見創建GPU集群、升級集群。

1.2 安裝配置ack-slurm-cluster組件

如需快速安裝、管理SlurmCluster，以及靈活調整集群配置，您可以使用Helm軟件包管理器來部署阿里云提供的SlurmClusterart。從charts-incubator中下載由阿里云包裝好的SlurmCluster的Helm，設置好相應的參數后，Helm會幫助您創建出RBAC、Configmap、Secret以及SlurmCuster等資源。

nodeSelector:
  example: example

tolerations:
- key:
  value:
  operator:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - zone-a
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: another-node-label-key
          operator: In
          values:
          - another-node-label-value

resources:
  requests:
    cpu: 1
  limits:
    cpu: 1

imagePullSecrets:
- name: example

podSecurityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  supplementalGroups: [4000]

securityContext:
  allowPrivilegeEscalation: false

具體操作如下所示：

1. 執行以下命令，將阿里云Helm倉庫添加到您的Helm客戶端。該操作將允許您訪問阿里云提供的各種Charts，包括ack-slurm-cluster組件。

   helm repo add aliyun https://aliacs-app-catalog.oss-cn-hangzhou.aliyuncs.com/charts-incubator/

2. 執行以下命令，拉取并解壓ack-slurm-cluster組件。該操作將會在當前目錄下創建一個名為ack-slurm-cluster的目錄，其中包含了Chart的所有文件和模板。

   helm pull aliyun/ack-slurm-cluster --untar=true

3. 執行以下命令，在名為values.yaml的文件中修改Chart參數。

   values.yaml文件包含了Chart的默認配置。您可以根據您的實際需求通過編輯這個文件來修改參數。例如Slurm的配置、資源請求與限制、存儲等。

   cd ack-slurm-cluster
   vi values.yaml

   展開查看如何生成JWT并提交到集群中

   生成JWT插件需要的key，并將生成的key通過以下命令導入集群中。具體操作，請參見JWT認證插件。

   1. 獲取JWK，實現JWT插件的簽名與認證。

      JWT認證插件通過Json Web Key(RFC7517)，實現JWT的簽名與認證，配置JWT認證插件首先需要生成一個有效的Json Web Key，您可以通過自行生成，或搜索Json Web Key Generator尋找可用的在線生成工具，如mkjwk.org，一個可用的Json Web Key大概如下所示，其中私鑰用于對Token進行簽名，公鑰需要配置在JWT認證插件中用于對Token進行驗證，一個合法的JWK大概格式如下：

      {
        "kty": "RSA",
        "e": "AQAB",
        "kid": "O9fpdhrViq2zaaaBEWZITz",
        "use": "sig",
        "alg": "RS256",
        "n": "qSVxcknOm0uCq5vGsOmaorPDzHUubBmZZ4UXj-9do7w9X1uKFXAnqfto4TepSNuYU2bA_-tzSLAGBsR-BqvT6w9SjxakeiyQpVmexxnDw5WZwpWenUAcYrfSPEoNU-0hAQwFYgqZwJQMN8ptxkd0170PFauwACOx4Hfr-9FPGy8NCoIO4MfLXzJ3mJ7xqgIZp3NIOGXz-GIAbCf13ii7kSStpYqN3L_zzpvXUAos1FJ9IPXRV84tIZpFVh2lmRh0h8ImK-vI42dwlD_hOIzayL1Xno2R0T-d5AwTSdnep7g-Fwu8-sj4cCRWq3bd61Zs2QOJ8iustH0vSRMYdP5oYQ"
      }        

      這里展示的是JSON格式，當使用YAML格式配置插件，需要轉換*

      • JWT認證插件只需要配置Public Key, 請妥善保存好您的Private Key，目前JWT認證插件支持以下算法：

      簽名算法	支持的alg取值
      RSASSA-PKCS1-V1_5 with SHA-2	RS256, RS384, RS512
      Elliptic Curve (ECDSA) with SHA-2	ES256, ES384, ES512
      HMAC using SHA-2	HS256, HS384, HS512

      重要

      當配置HS256,HS384,HS512類型的Key時，密鑰需要為Base64 UrlEncode后的值，如遇到Invalid Signature問題，請檢查您的Key的格式是否與生成Token的Key一致

   2. 將獲取的JWK導入集群中。

      kubectl create configmap jwt --from-literal=jwt_hs256.key={{ .jwtkey }}

   展開查看如何聲明數據庫地址和配置gres

   開啟Slurmrestd和Slurmdbd。修改values.yaml的.Values.slurmConfigs.filesInConfigMap字段聲明數據庫地址以及gres配置，配置文件中的數據庫地址可以使用阿里云RDS地址，也可以使用自建數據庫地址。

   slurmConfigs:
     ...
     filesInConfigMap:
       gres.conf: |
         # 用于Copilot將Kubernetes已分配資源同步至Slurm
         Name=k8scpu Flags=CountOnly
         Name=k8smemory Flags=CountOnly
       slurmdbd.conf: |
         # 日志路徑，需要與下面驗證時的路徑相同
         LogFile=/var/log/slurmdbd.log
         # 使用slurmrestd時必須指定jwt認證
         AuthAltTypes=auth/jwt
         # Slurmdbd需要使用該路徑中的Key認證token。需要配合下文將Key掛載到Pod中
         AuthAltParameters=jwt_key=/var/jwt/jwt_hs256.key
         AuthType=auth/munge
         SlurmUser=slurm
         # 設置mysql數據庫賬號信息
         StoragePass=
         StorageHost=
         StorageType=accounting_storage/mysql
         StorageUser=root
         StoragePort=3306
       slurm.conf: |
         # 用于在節點加入Slurm集群中設置k8scpu，k8smemory擴展資源屬性，防止節點被設置為DOWN狀態
         NodeFeaturesPlugins=node_features/k8s_resources
         # 用于Slurm中提交任務時自動添加k8scpu，k8smemory兩種擴展資源
         JobSubmitPlugins=k8s_resource_completion
         AccountingStorageHost=slurm-test-slurmdbd
         # 使用slurmrestd時必須指定jwt認證
         AuthAltTypes=auth/jwt
         # Slurmctld需要使用該路徑中的Key生成token。需要配合下文將Key掛載到Pod中
         AuthAltParameters=jwt_key=/var/jwt/jwt_hs256.key
         # 用于Copilot將Kubernetes已分配資源同步至Slurm
         GresTypes=k8scpu，k8smemory
         # 填寫${slurmClusterName}-slurmdbd，slurmOperator將會自動創建對應的slurmdbd服務
         AccuntingStorageHost=
         AccountingStoragePort=6819
         AccountingStorageType=accounting_storage/slurmdbd
         # 設置JobComp插件使用mysql數據庫時的信息
         JobCompHost=
         JobCompLoc=/var/log/slurm/slurm_jobcomp.log
         JobCompPass=
         JobCompPort=3306
         JobCompType=jobcomp/mysql
         JobCompUser=root
         # 高可用配置
         SlurmctldHost=

   展開查看如何設置Slurmrestd Pod和Slurmdbd Pod相關配置

   設置Slurmrestd Pod以及Slurmdbd Pod相關配置。

   ...
   headNodeConfig:
     image: "registry-cn-hangzhou.ack.aliyuncs.com/acs/slurm:23.06-1.6-aliyun-49259f59"
     # 將創建出的JWT Key掛載到Slurm中，與上文配置文件中的路徑對應
     volumes: 
     - configMap:
         defaultMode: 444
         name: jwt
       name: config-jwt
     volumeMounts: 
     - mountPath: /var/jwt
       name: config-jwt
   slurmdbdConfigs:
     nodeSelector: {}
     tolerations: []
     affinity: {}
     resources: {}
     image: "registry-cn-hangzhou.ack.aliyuncs.com/acs/slurm:23.06-1.6-aliyun-49259f59"
     imagePullSecrets: []
     # if .slurmConfigs.createConfigsByConfigMap is true， slurmConfPath and volume and volumeMounts will be auto set as:
     #  volumeMounts:
     #    - name: config-{{ .Values.slurmConfigs.configMapName }}
     #      mountPath: {{ .Values.slurmConfigs.slurmConfigPathInPod }}
     # volumes:
     #   - name: config-{{ .Values.slurmConfigs.configMapName }}
     #     configMap:
     #       name: {{ .Values.slurmConfigs.configMapName }}
     # also for mungeConfigs.createConfigsBySecret
     # 將創建出的JWT Key掛載到Slurm中，與上文配置文件中的路徑對應
   
     volumes: 
     - configMap:
         defaultMode: 444
         name: jwt
       name: config-jwt
     volumeMounts: 
     - mountPath: /var/jwt
       name: config-jwt
   
   slurmrestdConfigs:
     nodeSelector: {}
     tolerations: []
     affinity: {}
     resources: {}
     image: "registry-cn-hangzhou.ack.aliyuncs.com/acs/slurm:23.06-1.6-aliyun-49259f59"
     imagePullSecrets: []
     # if .slurmConfigs.createConfigsByConfigMap is true， slurmConfPath and volume and volumeMounts will be auto set as:
     #  volumeMounts:
     #    - name: config-{{ .Values.slurmConfigs.configMapName }}
     #      mountPath: {{ .Values.slurmConfigs.slurmConfigPathInPod }}
     # volumes:
     #   - name: config-{{ .Values.slurmConfigs.configMapName }}
     #     configMap:
     #       name: {{ .Values.slurmConfigs.configMapName }}
     # also for mungeConfigs.createConfigsBySecret
     # 將創建出的JWT Key掛載到Slurm中，與上文配置文件中的路徑對應
     volumes: 
     - configMap:
         defaultMode: 444
         name: jwt
       name: config-jwt
     volumeMounts: 
     - mountPath: /var/jwt
       name: config-jwt

4. 使用Helm安裝Chart，執行以下命令將會部署ack-slurm-cluster組件。（如果已經安裝了ack-slurm-cluster，可以使用helm upgrade命令更新helm chart。更新后需要手動清理已有Pod以及Slurmctld的StatefulSet完成配置更新。）

   cd ..
   helm install my-slurm-cluster ack-slurm-cluster # my-slurm-cluster可以根據實際情況進行更改。

5. 通過Helm安裝之后可以通過Helm list查看當前的ack-slurm-cluster是否完成安裝。

   Helm list

   預期輸出結果如下。

   NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
   ack-slurm-cluster       default         1               2024-07-19 14:47:58.126357 +0800 CST    deployed        ack-slurm-cluster-2.0.0 2.0.0      

6. 驗證Slurmrestd & Slurmdbd正常啟動

   1. 通過kubectl連接集群查看slurmdbd Pod是否正常啟動。

      kubectl get pod

      預期輸出結果如下，可以看到此時集群中有1個Worker節點和3個控制面組件的Pod。

      NAME                          READY   STATUS    RESTARTS   AGE
      slurm-test-slurmctld-dlncz    1/1     Running   0          3h49m
      slurm-test-slurmdbd-8f75r     1/1     Running   0          3h49m
      slurm-test-slurmrestd-mjdzt   1/1     Running   0          3h49m
      slurm-test-worker-cpu-0       1/1     Running   0          166m

   2. 執行以下命令查看日志信息，了解Slurmdbd是否已經正常啟動。

      kubectl exec slurm-test-slurmdbd-8f75r cat /var/log/slurmdbd.log | head

      預期輸出結果如下。

      kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
      [2024-07-22T19:52:55.727] accounting_storage/as_mysql: _check_mysql_concat_is_sane: MySQL server version is: 8.0.34
      [2024-07-22T19:52:55.737] error: Database settings not recommended values: innodb_lock_wait_timeout
      [2024-07-22T19:52:56.089] slurmdbd version 23.02.7 started

2.1 驗證負載混合調度功能

1. 查看genericnode狀態，可以看到Slurm與Kubernetes的負載狀態。

   kubectl get genericnode

   預期輸出結果如下。

   NAME                    CLUSTERNAME   ALIAS                     TYPE    ALLOCATEDRESOURCES
   cn-hongkong.10.1.0.19                 slurm-test-worker-cpu-0   Slurm   [{"allocated":{"cpu":"0"，"memory":"0"}，"type":"Slurm"}，{"allocated":{"cpu":"1735m"，"memory":"2393Mi"}，"type":"Kubernetes"}]

2. 提交一個任務到Slurm集群中，相關命令和預期輸出結果如下，可以看到Kubernetes的任務和Slurm的任務資源使用量都反映在了GenericNode上。

   root@iZj6c1wf3c25dbynbna3qgZ ~]# kubectl exec slurm-test-slurmctld-dlncz -- nohup srun --cpus-per-task=3 --mem=4000 --gres=k8scpu:3，k8smemory:4000 sleep inf &
   [1] 4132674
   
   [root@iZj6c1wf3c25dbynbna3qgZ ~]# kubectl scale deployment nginx-deployment-basic --replicas 2
   deployment.apps/nginx-deployment-basic scaled
   
   [root@iZj6c1wf3c25dbynbna3qgZ ~]# kubectl get genericnode
   NAME                    CLUSTERNAME   ALIAS                     TYPE    ALLOCATEDRESOURCES
   cn-hongkong.10.1.0.19                 slurm-test-worker-cpu-0   Slurm   [{"allocated":{"cpu":"3"，"memory":"4000Mi"}，"type":"Slurm"}，{"allocated":{"cpu":"2735m"，"memory":"3417Mi"}，"type":"Kubernetes"}]

3. 此時再提交一個任務到Slurm集群中，可以看到第2個提交的任務進入了PD（Pending）狀態。

   [root@iZj6c1wf3c25dbynbna3qgZ ~]# kubectl exec slurm-test-slurmctld-dlncz -- nohup srun --cpus-per-task=3 --mem=4000 sleep inf &
   [2] 4133454
   
   [root@iZj6c1wf3c25dbynbna3qgZ ~]# srun: job 2 queued and waiting for resources
   
   [root@iZj6c1wf3c25dbynbna3qgZ ~]# kubectl exec slurm-test-slurmctld-dlncz -- squeue
    JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
        2     debug    sleep     root PD       0:00      1 (Resources)
        1     debug    sleep     root  R       2:34      1 slurm-test-worker-cpu-0

在上述的srun的示例中，我們并沒有指定gres擴展資源，是由于在slurm集群啟動時已經加載了job_resource_completion插件，該插件會自動根據cpu和mem的請求量生成對應的gres資源量。如果沒有開啟該插件，您需要手動指定，本例中需要指定的額外參數為--gres=k8scpu:3,k8smemory:4000。如果您需要了解關于Slurm任務腳本參數是如何設置的，您可以展開查看下述內容。

#!/bin/bash
#SBATCH --job-name=test_job                   # 任務名字
#SBATCH --nodes=2                             # 需要的節點數量
#SBATCH --ntasks-per-node=4                   # 每個節點的任務數量
#SBATCH --cpus-per-task=2                     # 每個任務的CPU核心數量
#SBATCH --time=01:00:00                       # 任務運行的最長時間
#SBATCH --output=job_output_%j.txt            # 標準輸出文件名稱
#SBATCH --error=job_error_%j.txt              # 錯誤輸出文件名稱

# 用戶的作業命令
srun my_program

sbatch --nodes=2 --ntasks-per-node=4 --cpus-per-task=2 --time=01:00:00 --job-name=test_job my_job_script.sh

（可選）2.2 拓展混合調度功能-非容器化Slurm集群