Container Service for Kubernetes:ACK クラスタのポッドとして Slurm 管理クラスタをデプロイおよび実行する

Kubernetes クラスター管理者としてログインする

Kubernetes クラスターの管理者は、Kubernetes クラスターを管理する権限を持っています。Slurm 管理対象クラスターは、Kubernetes クラスター内のポッドとして実行されます。そのため、Kubernetes クラスター管理者は kubectl を使用して Kubernetes クラスター内の任意の Slurm 管理対象クラスターの任意のポッドにログインでき、デフォルトで Slurm 管理対象クラスターの root ユーザーの権限を持ちます。

Slurm 管理対象クラスターのポッドにログインするには、次のコマンドを実行します。

# クラスター内のポッド名で slurm-job-demo-xxxxx を置き換えます。
kubectl exec -it slurm-job-demo-xxxxx -- bash

Slurm 管理対象クラスターの一般ユーザーとしてログインする

Slurm 管理対象クラスターの管理者または一般ユーザーは、kubectl exec コマンドを実行する権限を持っていない場合があります。 Slurm 管理対象クラスターを管理者または一般ユーザーとして使用する場合、SSH を使用して Slurm 管理対象クラスターにログインする必要があります。

• 長期接続とスケーラビリティのために、サービスの外部 IP アドレスを使用してヘッドポッドにログインできます。このソリューションは、長期的な安定した接続が必要なシナリオに適しています。 Server Load Balancer（SLB）インスタンスとその関連付けられた外部 IP アドレスを使用して、内部ネットワーク内のどこからでも Slurm 管理対象クラスターにアクセスできます。

• port-forward コマンドを使用して、一時的にリクエストを転送できます。このソリューションは、kubectl port-forward コマンドの継続的な実行に依存しているため、短期の O&M またはデバッグに適しています。

ノード間でユーザーを同期する

Slurm は一元化されたユーザー認証サービスを提供していません。sbatch コマンドを実行して Slurm 管理クラスタにジョブを送信する場合、ジョブを送信したユーザーのアカウントが、ジョブの実行に選択されたノードに存在しない場合、ジョブの実行に失敗する可能性があります。この問題を解決するには、ユーザーを管理するために Slurm 管理クラスタの Lightweight Directory Access Protocol (LDAP) を構成します。 LDAP は、認証するための中央集中型バックエンド サービスとして機能します。このようにして、Slurm はサービスに基づいてユーザー ID を認証できます。次の操作を実行します。

1. ldap.yaml という名前のファイルを作成し、次の内容をファイルにコピーして、ユーザー情報を保存および管理する基本 LDAP インスタンスを作成します。

   ldap.yaml ファイルは、LDAP バックエンド ポッドとそれに関連付けられたサービスを定義します。ポッドには LDAP コンテナが含まれており、サービスは LDAP サービスを公開して、ネットワーク内で LDAP サービスにアクセスできるようにします。

   LDAP バックエンド ポッドとそれに関連付けられたサービスを表示する

   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: default
     name: ldap
     labels:
       app: ldap
   spec:
     selector:
       matchLabels:
         app: ldap
     revisionHistoryLimit: 10
     template:
       metadata:
         labels:
           app: ldap
       spec:
         securityContext:
           seLinuxOptions: {}
         imagePullSecrets: []
         restartPolicy: Always
         initContainers: []
         containers:
           - image: 'osixia/openldap:1.4.0'
             imagePullPolicy: IfNotPresent
             name: ldap
             volumeMounts:
               - name: openldap-data
                 mountPath: /var/lib/ldap
                 subPath: data
               - name: openldap-data
                 mountPath: /etc/ldap/slapd.d
                 subPath: config
               - name: openldap-data
                 mountPath: /container/service/slapd/assets/certs
                 subPath: certs
               - name: secret-volume
                 mountPath: /container/environment/01-custom
               - name: container-run
                 mountPath: /container/run
             args:
               - '--copy-service'
             resources:
               limits:
               requests:
             env: []
             readinessProbe:
               tcpSocket:
                 port: openldap
               initialDelaySeconds: 20
               timeoutSeconds: 1
               periodSeconds: 10
               successThreshold: 1
               failureThreshold: 10
             livenessProbe:
               tcpSocket:
                 port: openldap
               initialDelaySeconds: 20
               timeoutSeconds: 1
               periodSeconds: 10
               successThreshold: 1
               failureThreshold: 10
             lifecycle: {}
             ports:
               - name: openldap
                 containerPort: 389
                 protocol: TCP
               - name: ssl-ldap-port
                 containerPort: 636
                 protocol: TCP
         volumes:
           - name: openldap-data
             emptyDir: {}
           - name: secret-volume
             secret:
               secretName: ldap-secret
               defaultMode: 420
               items: []
           - name: container-run
             emptyDir: {}
         dnsPolicy: ClusterFirst
         dnsConfig: {}
         terminationGracePeriodSeconds: 30
     progressDeadlineSeconds: 600
     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 25%
         maxSurge: 25%
     replicas: 1
   ---
   apiVersion: v1
   kind: Service
   metadata:
     annotations: {}
     labels:
       app: ldap
     name: ldap-service
     namespace: default
   spec:
     ports:
       - name: openldap
         port: 389
         protocol: TCP
         targetPort: openldap
       - name: ssl-ldap-port
         port: 636
         protocol: TCP
         targetPort: ssl-ldap-port
     selector:
       app: ldap
     sessionAffinity: None
     type: ClusterIP
   ---
   metadata:
     name: ldap-secret
     namespace: default
     annotations: {}
   data:
     env.startup.yaml: >-
       # これはデフォルトのイメージ起動設定ファイルです
       # このファイルは、コンテナの**最初の起動**で**起動ファイル**で使用される環境変数を定義します。
   
       # このファイルは、起動ファイルが初めて処理された直後に削除されます。
       # これらの値はすべて、コンテナ環境では使用できなくなります。
       # これにより、コンテナ構成を非公開に保つことができます。
       # 詳細情報： https://github.com/osixia/docker-light-baseimage
   
       # 必須で、新しい ldap サーバーにのみ使用されます。
       LDAP_ORGANISATION: Example Inc.
       LDAP_DOMAIN: example.org
       LDAP_BASE_DN: #空の場合、LDAP_DOMAIN から自動的に設定されます
       LDAP_ADMIN_PASSWORD: admin
       LDAP_CONFIG_PASSWORD: config
       LDAP_READONLY_USER: false
       LDAP_READONLY_USER_USERNAME: readonly
       LDAP_READONLY_USER_PASSWORD: readonly
   
       # バックエンド
       LDAP_BACKEND: hdb
   
       # TLS
       LDAP_TLS: true
       LDAP_TLS_CERT_FILENAME: ldap.crt
       LDAP_TLS_KEY_FILENAME: ldap.key
       LDAP_TLS_CA_CERT_FILENAME: ca.crt
   
       LDAP_TLS_ENFORCE: false
       LDAP_TLS_CIPHER_SUITE: SECURE256:-VERS-SSL3.0
       LDAP_TLS_PROTOCOL_MIN: 3.1
       LDAP_TLS_VERIFY_CLIENT: demand
   
       # レプリケーション
       LDAP_REPLICATION: false
       # 変数 LDAP_BASE_DN、 LDAP_ADMIN_PASSWORD、 LDAP_CONFIG_PASSWORD
       # は実行時に自動的に複製されます
   
       # 既存の ldap にレプリケーションを追加する場合
       # 構成に LDAP_REPLICATION_CONFIG_SYNCAPROV と LDAP_REPLICATION_DB_SYNCAPROV を追加してください
       # $LDAP_BASE_DN、$LDAP_ADMIN_PASSWORD、$LDAP_CONFIG_PASSWORD 変数を使用しないでください
       LDAP_REPLICATION_CONFIG_SYNCAPROV: binddn="cn=admin,cn=config" bindmethod=simple credentials=$LDAP_CONFIG_PASSWORD searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1 starttls=critical
       LDAP_REPLICATION_DB_SYNCAPROV: binddn="cn=admin,$LDAP_BASE_DN" bindmethod=simple credentials=$LDAP_ADMIN_PASSWORD searchbase="$LDAP_BASE_DN" type=refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1 starttls=critical
       LDAP_REPLICATION_HOSTS: 
         - ldap://ldap.example.org # すべての ldap サーバーで順序が同じである必要があります
         - ldap://ldap2.example.org
   
   
       # 設定後、設定を削除する
       LDAP_REMOVE_CONFIG_AFTER_SETUP: true
   
       # cfsls 環境変数プレフィックス
       LDAP_CFSSL_PREFIX: ldap # cfsls-helper は最初に LDAP_CFSSL_* 変数、次に CFSSL_* 変数を検索します。
     env.yaml: >-
       # これはデフォルトのイメージ設定ファイルです
       # これらの値はコンテナ環境に保持されます。
   
       >
       コンテナの最初の起動後に使用されるすべての環境変数
       # はここで定義する必要があります。
       # 詳細情報： https://github.com/osixia/docker-light-baseimage
   
       # 一般的なコンテナ構成
       # http://www.openldap.org/doc/admin24/slapdconf.html の表 5.1 を参照して、使用可能なログ レベルを確認してください。
       LDAP_LOG_LEVEL: 256
   type: Opaque
   kind: Secret
   apiVersion: v1
   

2. 次のコマンドを実行して、LDAP バックエンド サービスをデプロイします。

   kubectl apply -f ldap.yaml

   期待される出力：

   deployment.apps/ldap created
   service/ldap-service created
   secret/ldap-secret created

3. オプション。 phpldapadmin.yaml という名前のファイルを作成し、次の内容をファイルにコピーして、LDAP フロントエンド ポッドとそれに関連付けられたサービスをデプロイします。 LDAP フロントエンド ポッドとそれに関連付けられたサービスは、管理効率を向上させるためにフロントエンド インターフェースを構成するために使用されます。

   LDAP フロントエンド ポッドとそれに関連付けられたサービスを表示する

   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: default
     name: phpldapadmin
     labels:
       io.kompose.service: phpldapadmin
   spec:
     selector:
       matchLabels:
         io.kompose.service: phpldapadmin
     revisionHistoryLimit: 10
     template:
       metadata:
         labels:
           io.kompose.service: phpldapadmin
       spec:
         securityContext:
           seLinuxOptions: {}
         imagePullSecrets: []
         restartPolicy: Always
         initContainers: []
         containers:
           - image: 'osixia/phpldapadmin:0.9.0'
             imagePullPolicy: Always
             name: phpldapadmin
             volumeMounts: []
             resources:
               limits:
               requests:
             env:
               - name: PHPLDAPADMIN_HTTPS
                 value: 'false'
               - name: PHPLDAPADMIN_LDAP_HOSTS
                 value: ldap-service
             lifecycle: {}
             ports:
               - containerPort: 80
                 protocol: TCP
         volumes: []
         dnsPolicy: ClusterFirst
         dnsConfig: {}
         terminationGracePeriodSeconds: 30
     progressDeadlineSeconds: 600
     strategy:
       type: RollingUpdate
       rollingUpdate:
         maxUnavailable: 25%
         maxSurge: 25%
     replicas: 1
   ---
   apiVersion: v1
   kind: Service
   metadata:
     namespace: default
     name: phpldapadmin
     annotations:
       k8s.kuboard.cn/workload: phpldapadmin
     labels:
       io.kompose.service: phpldapadmin
   spec:
     selector:
       io.kompose.service: phpldapadmin
     type: ClusterIP
     ports:
       - port: 8080
         targetPort: 80
         protocol: TCP
         name: '8080'
         nodePort: 0
     sessionAffinity: None

   次のコマンドを実行して、LDAP フロントエンド サービスをデプロイします。

   kubectl apply -f phpldapadmin.yaml

4. ステップ 3 に基づいて Slurm 管理クラスタのポッドにログオンし、次のコマンドを実行して LDAP クライアント パッケージをインストールします。

   apt update
   apt install libnss-ldapd

5. libnss-ldapd パッケージがインストールされた後、ポッド内の Slurm 管理クラスタのネットワーク認証サービスを構成します。

   1. 次のコマンドを実行して、スクリプトとファイルを編集するための Vim パッケージをインストールします。

      apt update
      apt install vim

   2. /etc/ldap/ldap.conf ファイルの次のパラメータを変更して、LDAP クライアントを構成します。

      ...
      BASE	dc=example,dc=org # 値を LDAP ディレクトリ構造のルートノードの識別名に置き換えます。
      URI	ldap://ldap-service # 値を LDAP サーバーの Uniform Resource Identifier (URI) に置き換えます。
      ...

   3. /etc/nslcd.conf ファイルの次のパラメータを変更して、LDAP サーバーへの接続を定義します。

      ...
      uri ldap://ldap-service # 値を LDAP サーバーの URI に置き換えます。
      base dc=example,dc=org # LDAP ディレクトリ構造に基づいてこのパラメータを指定します。
      ...
      tls_cacertfile /etc/ssl/certs/ca-certificates.crt # LDAP サーバーの証明書を検証するために使用される認証局 (CA) 証明書ファイルへのパスを指定します。
      ...

ログを共有およびアクセスする

デフォルトでは、sbatch コマンドを使用するときに生成されるジョブ ログは、ジョブを実行するノードに直接保存されます。これは、ログを表示するのに不便な場合があります。ログを簡単に表示するには、File Storage NAS (NAS) ファイルシステムを作成して、アクセス可能なディレクトリにすべてのジョブ ログを保存します。このようにして、計算ジョブが異なるノードで実行された場合でも、ジョブ用に生成されたログを一元的に収集して保存できます。これはログ管理を容易にします。次の操作を実行します。

1. 各ノードのログを保存および共有するための NAS ファイルシステムを作成します。詳細については、「ファイルシステムを作成する」をご参照ください。

2. [ACK コンソール] にログオンし、NAS ファイルシステムの永続ボリューム (PV) と永続ボリューム要求 (PVC) を作成します。詳細については、「静的にプロビジョニングされた NAS ボリュームをマウントする」をご参照ください。

3. SlurmCluster CR を変更します。

   headGroupSpec パラメータと workerGroupSpec パラメータの volumeMounts パラメータと volumes パラメータを構成して、作成された PVC を参照し、PVC を /home ディレクトリにマウントします。例：

   headGroupSpec:
   ...
   # マウントポイントとして /home を指定します。
     volumeMounts:
     - mountPath: /home
       name: test  # PVC を参照するボリュームの名前。
     volumes:
   # PVC の定義を追加します。
     - name: test  # このパラメータの値は、volumeMounts パラメータの name パラメータの値と同じである必要があります。
       persistentVolumeClaim:
         claimName: test  # 値を PVC の名前に置き換えます。
   ...
   workerGroupSpecs:
     # ... 各 workerGroupSpec パラメータの volume パラメータと volumeMounts パラメータの構成の前述のプロセスを繰り返します。

4. 次のコマンドを実行して、SlurmCluster CR をデプロイします。

   重要

   SlurmCluster CR のデプロイに失敗した場合は、kubectl delete slurmcluster slurm-job-demo コマンドを実行して CR を削除し、再デプロイします。

   kubectl  apply -f slurmcluster.yaml

   SlurmCluster CR がデプロイされると、ワーカー ノードは NAS ファイルシステムを共有できます。

Slurm 管理クラスタの自動スケーリングを実行する

デフォルトの Slurm イメージのルート パスには、slurm-resume.sh、slurm-suspend.sh、slurmctld-copilot などの実行可能ファイルとスクリプトが含まれています。これらは、slurmctld と対話して Slurm 管理クラスタをスケーリングするために使用されます。

クラウド上のノードに基づく Slurm クラスタの自動スケーリング

• ローカル ノード：slurmctld に直接接続されている物理計算ノード。

• クラウド上のノード：論理ノード。論理ノードは、クラウド サービス プロバイダーがオンデマンドで作成および破棄できる VM インスタンスです。

ACK での Slurm の自動スケーリング

手順

1. 自動スケーリング権限を構成します。Helm がインストールされている場合、自動スケーリング権限は slurmctld ポッドに対して自動的に構成されます。このステップはスキップできます。

   ヘッド ポッドには、自動スケーリングのために SlurmCluster CR にアクセスして更新するための権限が必要です。したがって、自動スケーリング機能を使用する場合は、RBAC を使用してヘッド ポッドに必要な権限を付与することをお勧めします。次の手順を実行して権限を構成できます。

   まず、slurmctld ポッドに必要なサービスアカウント、ロール、およびロール バインディングを作成する必要があります。例：Slurm 管理クラスタの名前を slurm-job-demo に設定し、名前空間を default に設定します。rbac.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: slurm-job-demo
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: slurm-job-demo
   rules:
   - apiGroups: ["kai.alibabacloud.com"]
     resources: ["slurmclusters"]
     verbs: ["get", "watch", "list", "update", "patch"]
     resourceNames: ["slurm-job-demo"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: slurm-job-demo
   subjects:
   - kind: ServiceAccount
     name: slurm-job-demo
   roleRef:
     kind: Role
     name: slurm-job-demo
     apiGroup: rbac.authorization.k8s.io

   kubectl apply -f rbac.yaml コマンドを実行して、リソース リストを送信します。

   slurmctld ポッドに権限を付与します。kubectl edit slurmcluster slurm-job-demo コマンドを実行して、Slurm 管理クラスタを変更します。Spec.Slurmctld.Template.Spec.ServiceAccountName パラメータを作成したサービスアカウントに設定します。

   apiVersion: kai.alibabacloud.com/v1
   kind: SlurmCluster
   ...
   spec:
     slurmctld:
       template:
         spec:
           serviceAccountName: slurm-job-demo
   ...

   slurmctld を管理する StatefulSet を再構築して、行った変更を適用します。kubectl get sts slurm-job-demo コマンドを実行して、slurmctld ポッドを管理する StatefulSet を見つけます。kubectl delete sts slurm-job-demo コマンドを実行して、この StatefulSet を削除します。Slurm Operator は StatefulSet を再構築し、新しい構成を適用します。

2. 自動スケーリング ファイル /etc/slurm/slurm.conf を構成します。

   共有ボリュームを使用して ConfigMap を管理する

   # クラウド上のノードを使用する場合は、次のパラメータが必要です。
   # SuspendProgram 機能と ResumeProgram 機能は、Alibaba Cloud によって開発されています。
   SuspendTimeout=600
   ResumeTimeout=600
   # ノードでジョブが実行されていないときにノードが自動的にサスペンドされる間隔。
   SuspendTime=600
   # 1 分あたりにスケーリングできるノード数を設定します。
   ResumeRate=1
   SuspendRate=1
   # NodeName パラメータの値を ${cluster_name}-worker-${group_name}- 形式で設定する必要があります。この行でノードのリソース量を指定する必要があります。そうしないと、slurmctld ポッドは
   # ノードに vCPU が 1 つだけあると見なします。クラウド上のノードで指定したリソースが、workerGroupSpec パラメータで宣言されたリソースと同じであることを確認してください。そうしないと、リソースが浪費される可能性があります。
   NodeName=slurm-job-demo-worker-cpu-[0-10] Feature=cloud State=CLOUD
   # 次の構成は固定されています。変更しないでください。
   CommunicationParameters=NoAddrCache
   ReconfigFlags=KeepPowerSaveSettings
   SuspendProgram="/slurm-suspend.sh"
   ResumeProgram="/slurm-resume.sh"

   ConfigMap を手動で管理する。

   slurm.conf が slurm-config の ConfigMap に保存されている場合は、kubectl edit slurm-config コマンドを実行して、次の構成を ConfigMap に追加できます。

   slurm.conf:
   ...
     # クラウド上のノードを使用する場合は、次のパラメータが必要です。
     # SuspendProgram 機能と ResumeProgram 機能は、Alibaba Cloud によって開発されています。
     SuspendTimeout=600
     ResumeTimeout=600
     # ノードでジョブが実行されていないときにノードが自動的にサスペンドされる間隔。
     SuspendTime=600
     # 1 分あたりにスケーリングできるノード数を設定します。
     ResumeRate=1
     SuspendRate=1
     # NodeName パラメータの値を ${cluster_name}-worker-${group_name}- 形式で設定する必要があります。この行でノードのリソース量を指定する必要があります。そうしないと、slurmctld ポッドは
     # ノードに vCPU が 1 つだけあると見なします。クラウド上のノードで指定したリソースが、workerGroupSpec パラメータで宣言されたリソースと同じであることを確認してください。そうしないと、リソースが浪費される可能性があります。
     NodeName=slurm-job-demo-worker-cpu-[0-10] Feature=cloud State=CLOUD
     # 次の構成は固定されています。変更しないでください。
     CommunicationParameters=NoAddrCache
     ReconfigFlags=KeepPowerSaveSettings
     SuspendProgram="/slurm-suspend.sh"
     ResumeProgram="/slurm-resume.sh"

   Helm を使用して ConfigMap を管理する

   1. 次の ConfigMap を values.yaml ファイルに追加します。

      slurm.conf:
      ...
        # クラウド上のノードを使用する場合は、次のパラメータが必要です。
        # SuspendProgram 機能と ResumeProgram 機能は、Alibaba Cloud によって開発されています。
        SuspendTimeout=600
        ResumeTimeout=600
        # ノードでジョブが実行されていないときにノードが自動的にサスペンドされる間隔。
        SuspendTime=600
        # 1 分あたりにスケーリングできるノード数を設定します。
        ResumeRate=1
        SuspendRate=1
        # NodeName パラメータの値を ${cluster_name}-worker-${group_name}- 形式で設定する必要があります。この行でノードのリソース量を指定する必要があります。そうしないと、slurmctld ポッドは
        # ノードに vCPU が 1 つだけあると見なします。クラウド上のノードで指定したリソースが、workerGroupSpec パラメータで宣言されたリソースと同じであることを確認してください。そうしないと、リソースが浪費される可能性があります。
        NodeName=slurm-job-demo-worker-cpu-[0-10] Feature=cloud State=CLOUD
        # 次の構成は固定されています。変更しないでください。
        CommunicationParameters=NoAddrCache
        ReconfigFlags=KeepPowerSaveSettings
        SuspendProgram="/slurm-suspend.sh"
        ResumeProgram="/slurm-resume.sh"

   2. helm upgrade コマンドを実行して、Slurm 構成を更新します。

3. 新しい構成を適用する

   Slurm 管理クラスタの名前が slurm-job-demo の場合は、kubectl delete sts slurm-job-demo コマンドを実行して、slurmctld ポッドの新しい構成を適用します。

4. slurmcluster.yaml ファイルのワーカー ノード レプリカの数を 0 に変更して、後続の手順でノード スケーリング アクティビティを表示できるようにします。

   手動管理

   Slurm 管理クラスタの名前を slurm-job-demo に設定します。kubectl edit slurmcluster slurm-job-demo コマンドを実行して、Slurm 管理クラスタの workerCount の値を 10 に変更します。この操作により、ワーカー ノード レプリカの数が 0 に変更されます。

   Helm を使用した管理

   values.yaml ファイルで、.Values.workerGroup[].workerCount パラメータを 0 に変更します。次に、helm upgrade slurm-job-demo . コマンドを実行して、現在の Helm チャートを更新します。この操作により、ワーカー ノード レプリカの数が 0 に設定されます。

5. sbatch コマンドを使用してジョブを送信します。

   1. 次のコマンドを実行して、シェル スクリプトを作成します。

      cat << EOF > cloudnodedemo.sh

      コマンド プロンプトの後に次の内容を入力します。

      > #!/bin/bash
      > srun hostname
      > EOF

   2. 次のコマンドを実行して、スクリプトの内容が正しいかどうかを確認します。

      cat cloudnodedemo.sh

      期待される出力：

        #!/bin/bash
        srun hostname

      出力は、スクリプトの内容が正しいことを示しています。

   3. 次のコマンドを実行して、処理のためにスクリプトを Slurm 管理クラスタに送信します。

      sbatch cloudnodedemo.sh

      期待される出力：

      Submitted batch job 1

      出力は、ジョブが送信され、ジョブ ID が割り当てられたことを示しています。

6. クラスタ スケーリングの結果を表示します。

   1. 次のコマンドを実行して、Slurm 管理クラスタのスケーリング ログを表示します。

      cat /var/log/slurm-resume.log

      期待される出力：

       namespace: default cluster: slurm-demo
        resume called, args [slurm-demo-worker-cpu-0]
        slurm cluster metadata: default slurm-demo
        get SlurmCluster CR slurm-demo succeed
        hostlists: [slurm-demo-worker-cpu-0]
        resume node slurm-demo-worker-cpu-0
        resume worker -cpu-0
        resume node -cpu-0 end

      出力は、Slurm 管理クラスタがワークロードに基づいて計算ノードを 1 つ自動的に追加して、送信されたジョブを実行することを示しています。

   2. 次のコマンドを実行して、クラスタ内のポッドを表示します。

      kubectl get pod

      期待される出力：

      NAME                                          READY   STATUS    RESTARTS        AGE
      slurm-demo-head-9hn67                         1/1     Running   0               21m
      slurm-demo-worker-cpu-0                       1/1     Running   0               43s

      出力は、slurm-demo-worker-cpu-0 ポッドがクラスタに追加されたことを示しています。この場合、ジョブが送信されるとクラスタはスケールアウトされます。

   3. 次のコマンドを実行して、クラスタ内のノードを表示します。

      sinfo

      期待される出力：

      PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
      debug*       up   infinite      10  idle~ slurm-job-demo-worker-cpu-[2-10]
      debug*       up   infinite      1   idle slurm-job-demo-worker-cpu-[0-1]

      出力は、slurm-demo-worker-cpu-0 ノードが新しく起動されたノードであり、さらに 10 個のクラウド上のノードがスケールアウトに使用できることを示しています。

   4. 次のコマンドを実行して、実行されたジョブに関する情報を表示します。

      scontrol show job 1

      期待される出力：

      JobId=1 JobName=cloudnodedemo.sh
         UserId=root(0) GroupId=root(0) MCS_label=N/A
         Priority=4294901757 Nice=0 Account=(null) QOS=(null)
         JobState=COMPLETED Reason=None Dependency=(null)
         Requeue=1 Restarts=0 BatchFlag=1 Reboot=0 ExitCode=0:0
         RunTime=00:00:00 TimeLimit=UNLIMITED TimeMin=N/A
         SubmitTime=2024-05-28T11:37:36 EligibleTime=2024-05-28T11:37:36
         AccrueTime=2024-05-28T11:37:36
         StartTime=2024-05-28T11:37:36 EndTime=2024-05-28T11:37:36 Deadline=N/A
         SuspendTime=None SecsPreSuspend=0 LastSchedEval=2024-05-28T11:37:36 Scheduler=Main
         Partition=debug AllocNode:Sid=slurm-job-demo:93
         ReqNodeList=(null) ExcNodeList=(null)
         NodeList=slurm-demo-worker-cpu-0
         BatchHost=slurm-demo-worker-cpu-0
         NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
         ReqTRES=cpu=1,mem=1M,node=1,billing=1
         AllocTRES=cpu=1,mem=1M,node=1,billing=1
         Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
         MinCPUsNode=1 MinMemoryNode=0 MinTmpDiskNode=0
         Features=(null) DelayBoot=00:00:00
         OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
         Command=//cloudnodedemo.sh
         WorkDir=/
         StdErr=//slurm-1.out
         StdIn=/dev/null
         StdOut=//slurm-1.out
         Power=

      出力の NodeList=slurm-demo-worker-cpu-0 は、ジョブが新しく追加されたノードで実行されていることを示しています。

   5. しばらくしてから、次のコマンドを実行して、ノード スケールインの結果を表示します。

      sinfo

      期待される出力：

      PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
      debug*       up   infinite     11  idle~ slurm-demo-worker-cpu-[0-10]

      出力は、スケールアウトに使用できるノードの数が 11 になったことを示しています。これは、自動スケールインが完了したことを示しています。