Slurm / sackd
===
###### tags: `Slurm`
###### tags: `Slurm`, `HPC`, `Linux`, `Slinky`, `SlinkyProject`, `sacctmgr`, `scontrol`, `sinfo`, `srun`, `AllowGroups`, `AllowAccounts`, `Hidden`, `PrivateData`

<br>

[TOC]

<br>

## sackd
> - **白話解釋**
> - 在 login node 上，執行 srun / sbatch / squeue / ... 時，要先跟叢集做認證才能授權執行
> - sackd (Slurm Auth and Cred Kiosk Daemon)，是用來協助 login 節點完成認證的角色
> - **核心概念**
> - `sackd` 是 Slurm 在「非計算節點（例如 login node/pod）」上提供的 **認證與憑證服務守護程序**，讓該節點能安全地和 `slurmctld` 互動。
> - 它通常以 **本機 Unix socket** 的形式提供服務端點，供同節點上的 Slurm client 指令使用。

- ### sackd 在 Slinky 中扮演的角色
- ### gpt-5.2 (2025/12/18)
在 **Slinky（Slurm-on-Kubernetes）** 的典型部署裡，`sackd` 通常是跑在 **Login Pod** 內的一個 Slurm 守護程序，角色/用途可以用「讓登入節點也能安全地跟 Slurm 叢集互動」來概括。 ([Amazon Web Services, Inc.][20251218-A-1])

### sackd 在 Slinky 中扮演的角色

* **補足 Login Pod 的「叢集認證能力」**：Login Pod 往往不跑 `slurmd`（那是 worker/compute pod 的 daemon），但使用者會在 Login Pod 上執行 `sbatch / srun / salloc` 等 Slurm client commands；`sackd` 就是用來讓這類「不跑 slurmd 的登入節點」仍能完成對叢集的認證與憑證處理。 ([Slurm][20251218-A-2])
* **支援 configless 架構（從 controller 拉設定）**：在 Slurm 的 configless 模式下，`sackd` 可以透過 `--conf-server <slurmctld host[:port]>` 向 `slurmctld` 取得設定並寫入快取（預設在 `/run/slurm/conf`，也可由 `RUNTIME_DIRECTORY` 調整）。這讓 Login Pod 不必在映像檔內硬塞完整設定檔，也比較符合雲原生的部署方式。 ([Slurm][20251218-A-2])
* **提供本機認證服務端點（Unix socket）**：`sackd` 會在 runtime 目錄下建立並維護 `sack.socket`（預設在 `/run/slurm/`，也可用 `RUNTIME_DIRECTORY` 改位置），讓同一個 pod 內的 Slurm client commands 能透過這個 socket 使用認證服務。 ([Slurm][20251218-A-2])

### 它「不是」做什麼

* `sackd` **不是排程器**（排程/決策仍在 `slurmctld`），也 **不負責啟動計算任務**（那是 `slurmd/slurmstepd` 的範疇）。它更像是 Login Pod 的「Slurm 認證/憑證前端」。 ([Slurm][2])

[20251218-A-1]: https://aws.amazon.com/blogs/containers/running-slurm-on-amazon-eks-with-slinky/ "Running Slurm on Amazon EKS with Slinky | Containers"
[20251218-A-2]: https://slurm.schedmd.com/sackd.html "Slurm Workload Manager - sackd"

- ### sackd 是採用 munge 加解密訊息嗎?
- ### gpt-5.2 (2025/12/18)
不一定；**取決於你在 `slurm.conf` 設定的 `AuthType`**。

* 如果叢集用的是 **`AuthType=auth/munge`**：Slurm 的認證會走 **MUNGE**（需要 `munged` 與共用的 `munge.key`），也就是你說的那種「用 MUNGE 產生/驗證憑證」的機制。 ([Slurm][20251218-B-1])
* 但 **`sackd` 本身是為 `auth/slurm`（SACK）設計的登入節點認證 daemon**：官方描述它是「Slurm Auth and Cred Kiosk Daemon」，用在**沒跑 `slurmd` 的 login node**，讓 client commands 也能對叢集完成認證；而且文件也明確提到「對於使用 `auth/slurm` 的站點，`sackd` 會提供 client commands 的認證」。 ([Slurm][20251218-B-2])

所以更精準地回答你的問題：

**在 `AuthType=auth/slurm` 的架構下，`sackd` 不依賴 MUNGE 來做認證；它走的是 Slurm 的 `auth/slurm`（SACK）機制。** ([Slurm][20251218-B-2])

想快速確認你目前是哪一種：看 `slurm.conf` 的 `AuthType`（`auth/munge` vs `auth/slurm`）就能判斷。 ([Slurm][20251218-B-1])

[20251218-B-1]: https://slurm.schedmd.com/authentication.html?utm_source=chatgpt.com "Authentication Plugins - Slurm Workload Manager -"
[20251218-B-2]: https://slurm.schedmd.com/sackd.html?utm_source=chatgpt.com "sackd - Slurm Workload Manager - SchedMD"

- ### 網際網路 & Slurm 叢集元件間 & LDAP 的通訊協定與安全機制
- ### gpt-5.2 (2025/12/18)
| 場景 | 主要通訊協定 | 安全機制 | 提供的安全性重點 | 常見連接埠 | 補充 |
|------|------------|----------|---------------|----------|------|
| 網際網路 Web/API | HTTP | TLS（= HTTPS） | 機密性（加密）+完整性+伺服器驗證（可選客戶端憑證） | 80/443 | 「SSL/TLS」多半是俗稱；現代以 TLS 為主 |
| Slurm 叢集元件間（controller/worker/login/db/clients） | Slurm RPC over TCP | AuthType（`auth/munge` 或 `auth/slurm`）+（可選）TLSType（TLS） | AuthType：通訊雙方驗證/憑證；TLSType：在傳輸層提供 TLS 加密/完整性 | 常見 6817/6818 等（依設定） | 官方文件明確指出 Slurm 元件間通訊會做驗證，且可透過 `TLSType` 啟用 TLS（如 `tls/s2n`）([Slurm](https://slurm.schedmd.com/quickstart_admin.html)) |
| LDAP client ↔ server | LDAP | TLS：StartTLS 或 LDAPS | 機密性（加密）+完整性；避免 simple bind 密碼明碼傳輸 | 389（ldap/StartTLS）、636（ldaps） | OpenLDAP 文件：TLS 可透過 StartTLS 或 `ldaps://`，且 StartTLS 是標準機制；也提到常見的 389/636 ([openldap.org](https://www.openldap.org/doc/admin24/security.html)) |


- ### 延伸閱讀
- [Kubernetes Operator for Slurm Clusters -- Controller](https://slinky.schedmd.com/projects/slurm-operator/en/release-1.0/index.html#controller)
> [\!NOTE] The kubelet’s `configMapAndSecretChangeDetectionStrategy` and `syncFrequency` settings directly affect when pods have their mounted ConfigMaps and Secrets updated. By default, the kubelet is in Watch mode with a polling frequency of 60 seconds.

<br>

## docs
https://slurm.schedmd.com/sackd.html

<br>

---

<br>

## 討論
### 詳細介紹 Slinky (Slurm-on-K8s) 中的 sackd 知識
> codebase: https://github.com/SlinkyProject/slurm-operator
- ### us.anthropic.claude-sonnet-4-5-20250929-v1:0 (2026/01/08)
根據我對 Slinky (Slurm-on-K8s) 項目的深入探索，以下是關於 **sackd** 的完整介紹：

---

## **Sackd 在 Slinky (Slurm-on-K8s) 中的詳細介紹**

### **一、什麼是 sackd？**

**sackd** (Slurm ACK Daemon) 是 Slurm 工作負載管理系統中的一個守護進程，專門用於 **Login 節點**的配置管理。在 Slinky 項目中，sackd 是 LoginSet 資源的核心組件之一。

### **二、sackd 在架構中的角色**

從代碼分析來看，sackd 在 Slinky 中扮演以下角色：

#### **1. LoginSet 的核心組件**
- LoginSet 是 Kubernetes 的自訂資源 (CRD)，用於管理 Slurm 登入節點
- LoginSet 的 kubectl 短名稱之一就是 `sackd`，顯示其重要性：

      // api/v1beta1/loginset_types.go:83
      // +kubebuilder:resource:shortName=loginsets;lss;sackd

#### **2. 與其他組件的組合**
從 Helm values.yaml 中可以看到，LoginSet Pod 包含三個主要組件：
- **sackd**: 配置服務守護進程
- **sshd**: SSH 服務
- **sssd**: 系統安全服務守護進程 (用於 LDAP/AD 整合)

### **三、sackd 的技術實現細節**

#### **1. Socket 通訊機制**
從代碼 `internal/builder/login_app.go` 中可以看到：

    const (
        sackdVolume = "sackd-dir"
        sackdDir    = "/run/slurm"
        sackdSocket     = "sack.socket"
        sackdSocketPath = "/run/slurm/sack.socket"
    )

sackd 使用 **Unix Socket** 進行本地通訊：
- Socket 路徑: `/run/slurm/sack.socket`
- 存儲在內存中 (EmptyDir with Memory medium)

#### **2. 健康檢查機制**
Login 容器的 ReadinessProbe 檢查 sackd socket 是否就緒：

    // internal/builder/login_app.go:267-277
    ReadinessProbe: &corev1.Probe{
        ProbeHandler: corev1.ProbeHandler{
            Exec: &corev1.ExecAction{
                Command: []string{
                    "test",
                    "-S",
                    sackdSocketPath,  // 檢查 socket 檔案是否存在
                },
            },
        },
    },

#### **3. Configless 配置模式**
sackd 使用 **configless** 模式運行，透過環境變數配置：

    // internal/builder/login_app.go:298-306
    func loginEnv(container corev1.Container, controller *slinkyv1beta1.Controller) []corev1.EnvVar {
        env := []corev1.EnvVar{
            {
                Name:  "SACKD_OPTIONS",
                Value: strings.Join(configlessArgs(controller), " "),
            },
        }
        return mergeEnvVar(env, container.Env, " ")
    }

#### **4. Configless 參數構建**
從 `internal/builder/common.go:55-68` 可以看到：

    func configlessArgs(controller *slinkyv1beta1.Controller) []string {
        host := controller.ServiceFQDNShort()
        port := SlurmctldPort
        if controller.Spec.External {
            externalConfig := controller.Spec.ExternalConfig
            host = externalConfig.Host
            port = externalConfig.Port
        }
        args := []string{
            "--conf-server",
            fmt.Sprintf("%s:%d", host, port),
        }
        return args
    }

**實際運行命令**:

    sackd --conf-server "${SLURMCTLD_HOST}:${SLURMCTLD_PORT}"

### **四、sackd 的配置與部署**

#### **1. Volume 掛載**
sackd 需要以下 Volume：

    // internal/builder/login_app.go:156-164
    {
        Name: sackdVolume,
        VolumeSource: corev1.VolumeSource{
            EmptyDir: &corev1.EmptyDirVolumeSource{
                Medium: corev1.StorageMediumMemory,  // 使用內存存儲
            },
        },
    },

容器內掛載：

    {Name: sackdVolume, MountPath: sackdDir}  // 掛載到 /run/slurm

#### **2. Helm 配置範例**
從 `helm/slurm/values.yaml:465-483` 可以看到：

    # Slurm LoginSet (sackd, sshd, sssd) configurations.
    loginsets:
      slinky:
        enabled: false
        replicas: 1
        login:
          image:
            repository: ghcr.io/slinkyproject/login
            tag: 25.11-ubuntu24.04
          env: []
            # - name: SACKD_OPTIONS
            #   value: -vvv  # 可以增加詳細日誌輸出

#### **3. 自訂 SACKD_OPTIONS**
使用者可以透過環境變數自訂 sackd 選項：

    login:
      env:
        - name: SACKD_OPTIONS
          value: -vvv  # 啟用詳細日誌模式

### **五、Hybrid 混合部署模式**

#### **外部 Login 節點部署**
根據文檔 `docs/usage/hybrid.md:177-185`，當 Login 主機位於 Kubernetes 外部時：

    # 外部啟動 sackd 的命令
    sackd --conf-server "${SLURMCTLD_HOST}:${SLURMCTLD_PORT}"

**要求**：
- 必須使用 configless Slurm 配置
- 必須使用 JWT 認證
- 需要能連接到 slurmctld 的主機和端口

### **六、系統需求**

根據 `docs/usage/system-requirements.md:132-133`：

> **sackd**: Treat like [munged] for the purposes of system requirements

- **資源需求**: 類似 munged，屬於輕量級守護進程
- **系統要求**: 低 CPU 和內存消耗
- **網路要求**: 需要能連接到 slurmctld

### **七、與其他 Slurm 組件的交互**

    ┌─────────────┐
    │  slurmctld  │  ← 配置服務器 (Slurm Controller)
    └──────┬──────┘
           │ TCP (port 6817)
           │ configless protocol
           ↓
    ┌─────────────┐
    │    sackd    │  ← 在 Login 節點運行
    └──────┬──────┘
           │ Unix Socket (/run/slurm/sack.socket)
           ↓
    ┌─────────────┐
    │ Slurm CLI   │  ← srun, sbatch, squeue 等命令
    │ (用戶工具)   │
    └─────────────┘

### **八、重要特性總結**

| 特性 | 說明 |
|------|------|
| **主要功能** | 為 Login 節點提供 Slurm 配置服務 |
| **通訊方式** | Unix Socket (`/run/slurm/sack.socket`) |
| **配置模式** | Configless (無需本地 slurm.conf) |
| **認證方式** | JWT |
| **部署位置** | Login Pod 容器內或外部 Login 主機 |
| **健康檢查** | 檢查 socket 文件存在性 |
| **資源消耗** | 低 (類似 munged) |

### **九、關鍵代碼位置**

- **API 定義**: `api/v1beta1/loginset_types.go:83`
- **容器構建**: `internal/builder/login_app.go:255-296`
- **環境變數**: `internal/builder/login_app.go:298-306`
- **Configless 參數**: `internal/builder/common.go:55-68`
- **Helm 配置**: `helm/slurm/values.yaml:465-483`
- **CRD 定義**: `config/crd/bases/slinky.slurm.net_loginsets.yaml:17`

### **十、總結**

**sackd** 是 Slinky 項目中實現 **Slurm Login 節點**的關鍵組件，它採用 **configless** 模式從 slurmctld 動態獲取配置，透過 Unix Socket 提供本地服務，並支援 Kubernetes 內外部的混合部署模式。這種設計使得 Login 節點的部署更加靈活且易於管理。

<br>

{%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}