Ray 分散式計算框架跨平台佈署實戰：從 Kubernetes 到 OpenShift 的完整指南

– 12 分鐘閱讀

在現代雲端運算架構中,分散式計算能力已經成為處理大規模資料與機器學習任務的核心基礎設施。隨著資料量的爆炸性成長與運算需求的複雜化,單機運算已經難以滿足企業級應用的效能要求。分散式計算框架透過將任務分散到多個運算節點,實現了運算資源的水平擴展,大幅提升了系統的處理能力與容錯性。

Ray 作為新一代的分散式計算框架,在設計理念上有著顯著的創新。相較於傳統的批次處理系統如 Apache Spark,Ray 提供了更靈活的程式設計模型,支援動態任務圖、嵌套並行與狀態共享等進階特性。這些能力讓 Ray 特別適合強化學習、超參數調優與即時推論等需要快速迭代與複雜互動的場景。從技術架構來看,Ray 採用了分散式物件儲存與任務排程的統一設計,透過 GCS 全域控制服務協調整個叢集的資源分配與狀態管理。

在企業級應用中,Ray 的部署環境選擇直接影響系統的可靠性與維護成本。IBM Cloud 提供了完整的雲端基礎設施,包括彈性的虛擬機器、高速網路與持久化儲存,適合需要穩定效能與合規要求的關鍵業務。Kubernetes 作為容器編排的事實標準,提供了自動擴展、服務發現與負載平衡等雲端原生能力,讓 Ray 叢集能夠與現代微服務架構無縫整合。OpenShift 則在 Kubernetes 基礎上增加了企業級的安全性、多租戶隔離與開發者工具,特別適合金融、醫療等對安全性與合規性要求嚴格的產業。

IBM Cloud 上的 Ray 叢集架構設計

在 IBM Cloud 環境中部署 Ray 叢集需要仔細規劃資源配置與網路拓撲。IBM Cloud 的虛擬私有雲提供了隔離的網路環境,讓 Ray 叢集能夠在安全的邊界內運作。子網路的劃分決定了節點之間的通訊延遲與頻寬,需要根據任務特性選擇適當的網路配置。

從架構設計的角度來看,Ray 叢集由頭節點與工作節點組成。頭節點承擔著叢集協調的關鍵角色,負責任務排程、資源管理與全域狀態維護。由於頭節點需要持續運行並處理來自客戶端的請求,其穩定性直接影響整個叢集的可用性。工作節點則負責執行實際的運算任務,可以根據工作負載動態擴展。這種分離式設計讓資源配置更加靈活,頭節點可以保持相對輕量的配置,而工作節點則可以配備更強大的運算資源。

在實務配置中,資源規劃需要考慮多個維度。CPU 核心數決定了並行任務的執行能力,記憶體容量則影響可處理的資料集大小與中間結果的快取能力。儲存配置包括開機磁碟區容量與效能層級,需要在成本與效能之間取得平衡。網路安全群組控制著節點之間的通訊規則,必須正確配置以確保 Ray 的內部通訊能夠正常運作。

# Ray 叢集在 IBM Cloud 上的完整組態定義
# 這個 YAML 檔案描述了叢集的網路、儲存與運算資源配置

# 叢集名稱,用於識別與管理
cluster_name: ray-production-cluster

# 網路配置區段
# 定義 Ray 叢集所使用的 VPC 與子網路
# VPC ID 唯一識別虛擬私有雲環境
vpc_id: r006-50485f78-a76f-4401-a742-ce0a748b46f9

# 子網路 ID 指定節點所在的網路區段
# 同一子網路內的節點享有低延遲通訊
subnet_id: 0737-213b5b33-cee3-41d0-8d25-95aef8e86470

# 儲存配置
# volume_tier_name 定義磁碟效能層級
# general-purpose 提供平衡的價格與效能
# 其他選項包括 10iops-tier (高效能) 與 5iops-tier (低成本)
volume_tier_name: general-purpose

# 頭節點配置區段
# 頭節點負責叢集協調與任務排程
head_node:
  # 運算資源配置
  # CPU 核心數影響並行排程能力
  # 頭節點通常不需要大量 CPU,4 核心足以應付中型叢集
  resources:
    CPU: 4
    memory: 16  # 記憶體以 GB 為單位
  
  # 節點配置細節
  node_config:
    # 開機磁碟區容量 (GB)
    # 需要足夠空間儲存系統、日誌與臨時檔案
    boot_volume_capacity: 100
    
    # 映像檔 ID 指定作業系統與預裝軟體
    # 這個映像應該包含 Ray 執行所需的 Python 環境
    image_id: r006-dd164da8-c4d9-46ba-87c4-03c614f0532c
    
    # 執行個體配置文件定義虛擬機器的規格
    # bx2-8x32 表示 8 個 vCPU 與 32 GB 記憶體
    instance_profile_name: bx2-8x32
    
    # SSH 金鑰 ID 用於遠端存取節點
    # 必須預先在 IBM Cloud 中建立金鑰對
    key_id: r006-d6d823da-5c41-4e92-a6b6-6e98dcc90c8e
    
    # 資源群組 ID 用於權限管理與成本追蹤
    resource_group_id: 5f6b028dc4ef41b9b8189bbfb90f2a79
    
    # 安全群組 ID 定義防火牆規則
    # 必須允許 Ray 所需的埠號 (6379, 8265, 10001 等)
    security_group_id: r006-c8e44f9c-7159-4041-a7ab-cf63cdb0dca7

# 工作節點配置區段
# 工作節點執行實際的運算任務
worker_nodes:
  # 預設工作節點配置
  # 這個配置會應用於所有動態建立的工作節點
  ray_worker_default:
    # 自動擴展參數
    # min_workers 為 0 表示在沒有任務時不保留工作節點
    # 這能夠節省運算成本
    min_workers: 0
    
    # max_workers 定義叢集的最大規模
    # 根據預期的工作負載設定適當的上限
    max_workers: 10
    
    # 運算資源配置
    # 工作節點通常需要更多 CPU 用於運算密集任務
    resources:
      CPU: 8
      memory: 32
    
    # 節點配置
    # 繼承頭節點的大部分配置,但調整資源規格
    node_config:
      boot_volume_capacity: 100
      image_id: r006-dd164da8-c4d9-46ba-87c4-03c614f0532c
      
      # 使用更高規格的執行個體配置文件
      # bx2-16x64 提供 16 個 vCPU 與 64 GB 記憶體
      instance_profile_name: bx2-16x64
      
      key_id: r006-d6d823da-5c41-4e92-a6b6-6e98dcc90c8e
      resource_group_id: 5f6b028dc4ef41b9b8189bbfb90f2a79
      security_group_id: r006-c8e44f9c-7159-4041-a7ab-cf63cdb0dca7
      subnet_id: 0737-213b5b33-cee3-41d0-8d25-95aef8e86470
      volume_tier_name: general-purpose
      vpc_id: r006-50485f78-a76f-4401-a742-ce0a748b46f9

# 初始化腳本
# 在節點啟動後執行的命令
setup_commands:
  # 更新套件列表
  - sudo apt-get update
  
  # 安裝 Python 與相依套件
  - sudo apt-get install -y python3-pip
  
  # 安裝 Ray 與必要的 Python 套件
  - pip3 install ray[default] pandas numpy

# 頭節點啟動命令
# 這些命令會在頭節點初始化時執行
head_start_ray_commands:
  # 啟動 Ray 頭節點
  # --port 指定 Ray 客戶端連線的埠號
  # --dashboard-port 指定 Web 儀表板的埠號
  # --autoscaling-config 啟用自動擴展功能
  - ray start --head --port=6379 --dashboard-port=8265 --autoscaling-config=~/ray_bootstrap_config.yaml

# 工作節點啟動命令
worker_start_ray_commands:
  # 工作節點連線到頭節點
  # --address 指定頭節點的位址
  - ray start --address=$RAY_HEAD_IP:6379

這個完整的組態範例展示了 Ray 叢集在 IBM Cloud 上的部署細節。網路配置確保了節點之間的安全通訊,儲存配置平衡了效能與成本,資源配置則根據角色差異化設定。自動擴展參數讓叢集能夠根據工作負載動態調整規模,在閒置時縮減到最小配置以節省成本,在高峰時擴展到最大容量以滿足效能需求。

在實際部署中,組態檔案需要根據具體的業務需求進行調整。對於機器學習訓練任務,可能需要配備 GPU 的執行個體配置文件。對於記憶體密集型應用,需要選擇記憶體最佳化的執行個體類型。網路安全群組的規則必須精確配置,既要允許 Ray 的內部通訊,又要限制不必要的外部存取。

部署流程從安裝 Gen2-connector 工具開始,這個工具提供了與 IBM Cloud API 的整合,能夠根據組態檔案自動建立與管理虛擬機器。

# 安裝 IBM Cloud Gen2 連接器
# 這個工具提供了與 IBM Cloud VPC 的整合
pip3 install gen2-connector

# 驗證安裝
gen2-connector --version

# 配置 IBM Cloud 認證
# 需要設定 API 金鑰與區域資訊
export IBMCLOUD_API_KEY="your-api-key-here"
export IBMCLOUD_REGION="us-south"

# 使用組態檔案建立 Ray 叢集
# ray up 命令會讀取 YAML 組態並自動建立所需資源
ray up cluster.yaml

# 監控叢集啟動過程
# 這個命令會顯示即時日誌,幫助診斷啟動問題
ray exec cluster.yaml 'tail -n 100 -f /tmp/ray/session_latest/logs/monitor*'

# 檢查叢集狀態
# 顯示頭節點與工作節點的運行狀況
ray status

# 連線到叢集進行互動式操作
ray attach cluster.yaml

# 在遠端叢集上執行 Python 腳本
ray submit cluster.yaml script.py

# 關閉叢集並清理資源
# 這個命令會終止所有虛擬機器並釋放相關資源
ray down cluster.yaml

叢集啟動後,Ray 會建立頭節點並等待其初始化完成,然後根據配置建立初始的工作節點。自動擴展功能會持續監控叢集的資源使用狀況,當任務佇列累積時自動新增工作節點,當資源閒置時自動移除節點。這種動態調整機制確保了資源利用率的最佳化。

Kubernetes 環境中的 Ray 部署策略

Kubernetes 作為容器編排平台,為 Ray 提供了更靈活的部署與管理能力。相較於直接在虛擬機器上部署,容器化的 Ray 叢集能夠更快速地啟動,更容易地遷移,並且能夠與現有的 Kubernetes 生態系統無縫整合。

Ray 在 Kubernetes 上提供了兩種主要的部署模式。叢集啟動器模式延續了在虛擬機器上的部署邏輯,透過 Kubernetes API 動態建立與管理 Pod。這種模式適合快速原型開發與實驗性部署,配置相對簡單。Operator 模式則採用了 Kubernetes 的 Custom Resource Definition 機制,定義了 RayCluster 這個自訂資源類型。Operator 控制器持續監控 RayCluster 資源的狀態,並確保實際運行的 Pod 與期望狀態保持一致。這種聲明式的管理方式更符合 Kubernetes 的設計理念,適合生產環境的長期運維。

在本地開發環境中,kind 提供了一個輕量級的 Kubernetes 叢集實作。kind 透過在 Docker 容器中運行 Kubernetes 節點,讓開發者能夠在筆記型電腦上快速建立測試環境。這種方式特別適合開發與測試 Ray 應用程式,避免了雲端資源的成本。

# 安裝 kind 工具
# macOS 使用 Homebrew
brew install kind

# Linux 使用二進位安裝
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# 建立 kind 叢集
# 預設配置會建立單節點叢集
kind create cluster --name ray-dev

# 使用自訂配置建立多節點叢集
# 這個配置建立 1 個控制平面節點與 3 個工作節點
cat <<EOF | kind create cluster --name ray-cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
- role: worker
EOF

# 驗證叢集狀態
kubectl cluster-info --context kind-ray-cluster
kubectl get nodes

# 安裝 Ray Operator
# 首先安裝 CRD 定義
kubectl create -k "github.com/ray-project/kuberay/ray-operator/config/crd?ref=v0.6.0"

# 安裝 Operator 控制器
kubectl create -k "github.com/ray-project/kuberay/ray-operator/config/default?ref=v0.6.0"

# 驗證 Operator 是否正常運行
kubectl get pods -n ray-system

完成 Kubernetes 叢集與 Ray Operator 的安裝後,就可以透過定義 RayCluster 資源來建立 Ray 叢集。這個資源的定義包含了頭節點與工作節點的 Pod 規格,包括容器映像、資源限制與環境變數。

# Ray 叢集的 Kubernetes 自訂資源定義
# 這個 YAML 檔案描述了完整的 Ray 叢集配置
apiVersion: ray.io/v1alpha1
kind: RayCluster
metadata:
  # 叢集名稱,在命名空間內必須唯一
  name: ray-cluster
  # 部署的命名空間
  namespace: default
spec:
  # Ray 版本
  # 指定要使用的 Ray 版本,影響容器映像的選擇
  rayVersion: '2.7.0'
  
  # 頭節點群組配置
  headGroupSpec:
    # 副本數量,頭節點通常只需要一個
    replicas: 1
    
    # Ray 啟動參數
    # 這些參數會傳遞給 ray start 命令
    rayStartParams:
      dashboard-host: '0.0.0.0'
      port: '6379'
      object-manager-port: '8076'
      node-manager-port: '8077'
      dashboard-port: '8265'
      metrics-export-port: '8080'
      num-cpus: '0'  # 頭節點不參與運算任務
    
    # Pod 範本定義
    template:
      spec:
        containers:
        - name: ray-head
          # Ray 官方容器映像
          # 選擇包含所需 Python 版本與相依套件的映像
          image: rayproject/ray:2.7.0-py310
          
          # 容器埠號定義
          # 這些埠號必須與 rayStartParams 一致
          ports:
          - containerPort: 6379
            name: gcs
          - containerPort: 8265
            name: dashboard
          - containerPort: 10001
            name: client
          - containerPort: 8076
            name: object-manager
          - containerPort: 8077
            name: node-manager
          
          # 資源請求與限制
          # requests 定義 Pod 調度的最小資源需求
          # limits 定義 Pod 可使用的最大資源
          resources:
            requests:
              cpu: "2"
              memory: "8Gi"
            limits:
              cpu: "4"
              memory: "16Gi"
          
          # 環境變數
          env:
          - name: RAY_GRAFANA_HOST
            value: http://prometheus-grafana.prometheus-system.svc:80
          
          # 存活性探測
          # 檢查容器是否正常運行
          livenessProbe:
            httpGet:
              path: /api/version
              port: 8265
            initialDelaySeconds: 30
            periodSeconds: 10
          
          # 就緒性探測
          # 檢查容器是否準備接受流量
          readinessProbe:
            httpGet:
              path: /api/version
              port: 8265
            initialDelaySeconds: 10
            periodSeconds: 5
          
          # 磁碟區掛載
          volumeMounts:
          - name: ray-logs
            mountPath: /tmp/ray
        
        # 磁碟區定義
        volumes:
        - name: ray-logs
          emptyDir: {}
  
  # 工作節點群組配置
  workerGroupSpecs:
  # 可以定義多個工作節點群組,每個群組有不同的配置
  - replicas: 3
    minReplicas: 1
    maxReplicas: 10
    
    # 群組名稱
    groupName: small-workers
    
    # Ray 啟動參數
    rayStartParams:
      num-cpus: '4'
      node-ip-address: $MY_POD_IP  # 使用 Pod IP 作為節點位址
    
    # Pod 範本
    template:
      spec:
        containers:
        - name: ray-worker
          image: rayproject/ray:2.7.0-py310
          
          # 資源配置
          # 工作節點需要更多資源執行運算任務
          resources:
            requests:
              cpu: "4"
              memory: "16Gi"
            limits:
              cpu: "8"
              memory: "32Gi"
          
          # 環境變數
          # MY_POD_IP 用於節點間通訊
          env:
          - name: MY_POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          
          # 存活性探測
          livenessProbe:
            exec:
              command:
              - /bin/sh
              - -c
              - ray health-check --address $(RAY_CLUSTER_HEAD_SERVICE):6379
            initialDelaySeconds: 60
            periodSeconds: 30
          
          volumeMounts:
          - name: ray-logs
            mountPath: /tmp/ray
        
        volumes:
        - name: ray-logs
          emptyDir: {}

這個 RayCluster 資源定義展示了完整的叢集配置。頭節點的 num-cpus 設定為 0,表示它不參與運算任務,專注於叢集協調。工作節點則配備了充足的 CPU 與記憶體資源。探測機制確保了 Kubernetes 能夠及時發現與處理異常狀況,當容器失敗時自動重啟。

服務發現是 Kubernetes 環境中的另一個重要主題。Ray 叢集需要穩定的網路端點讓客戶端與節點能夠連線。Kubernetes Service 資源提供了這個能力,為 Ray 頭節點建立一個固定的 DNS 名稱與 ClusterIP。

# Ray 頭節點的 Service 定義
# 這個 Service 提供了穩定的網路端點
apiVersion: v1
kind: Service
metadata:
  name: ray-head-svc
  namespace: default
spec:
  # 選擇器用於匹配 Pod
  # 只有帶有這些標籤的 Pod 才會被加入 Service
  selector:
    ray.io/cluster: ray-cluster
    ray.io/node-type: head
  
  # 埠號定義
  ports:
  # GCS 服務埠,用於叢集內部通訊
  - name: gcs
    port: 6379
    targetPort: 6379
    protocol: TCP
  
  # 儀表板埠,提供 Web UI
  - name: dashboard
    port: 8265
    targetPort: 8265
    protocol: TCP
  
  # 客戶端連線埠
  - name: client
    port: 10001
    targetPort: 10001
    protocol: TCP
  
  # Service 類型
  # ClusterIP 僅在叢集內部可存取
  # 如果需要外部存取,可以使用 LoadBalancer 或 NodePort
  type: ClusterIP

---
# Ingress 資源定義
# 提供從叢集外部存取 Ray 儀表板的能力
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ray-dashboard
  namespace: default
  annotations:
    # Ingress 類別,通常是 nginx
    kubernetes.io/ingress.class: nginx
    
    # 啟用 SSL
    cert-manager.io/cluster-issuer: letsencrypt-prod
    
    # NGINX 特定配置
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  # TLS 配置
  tls:
  - hosts:
    - ray.example.com
    secretName: ray-tls-secret
  
  # 路由規則
  rules:
  - host: ray.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ray-head-svc
            port:
              number: 8265

這個 Service 與 Ingress 配置讓 Ray 叢集能夠被存取。Service 提供了叢集內部的穩定端點,Ingress 則提供了從外部網路存取儀表板的路徑。需要注意的是,Ray 客戶端使用 gRPC 協定進行通訊,而許多 Ingress 控制器對 gRPC 的支援有限制。NGINX Ingress 控制器僅支援使用 TLS 的安全 gRPC 連線,這意味著如果要透過 Ingress 暴露 Ray 的客戶端埠,必須配置適當的 TLS 證書。

部署與驗證流程包含多個步驟,從建立資源到測試叢集功能。

# 建立命名空間
kubectl create namespace ray

# 部署 RayCluster 資源
kubectl apply -f ray-cluster.yaml -n ray

# 監控 Pod 啟動
kubectl get pods -n ray -w

# 查看叢集狀態
kubectl describe raycluster ray-cluster -n ray

# 查看頭節點日誌
kubectl logs -n ray -l ray.io/node-type=head -f

# 建立測試 Job
# 這個 Job 會連線到 Ray 叢集並執行簡單的測試
cat <<EOF | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: ray-test-job
  namespace: ray
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: ray-client
        image: rayproject/ray:2.7.0-py310
        command:
        - python
        - -c
        - |
          import ray
          # 連線到 Ray 叢集
          ray.init(address='ray-head-svc:10001')
          
          # 定義遠端函式
          @ray.remote
          def hello_world():
              return "Hello from Ray!"
          
          # 執行遠端函式
          futures = [hello_world.remote() for _ in range(10)]
          results = ray.get(futures)
          
          print("Test results:", results)
          print("Ray cluster resources:", ray.cluster_resources())
EOF

# 查看測試結果
kubectl logs -n ray job/ray-test-job

# 埠轉發存取儀表板
kubectl port-forward -n ray service/ray-head-svc 8265:8265

# 在瀏覽器中開啟 http://localhost:8265 檢視儀表板

# 清理資源
kubectl delete raycluster ray-cluster -n ray
kubectl delete job ray-test-job -n ray

這些命令展示了完整的部署與測試流程。測試 Job 驗證了叢集的基本功能,包括客戶端連線、遠端函式執行與資源查詢。埠轉發讓開發者能夠從本地瀏覽器存取 Ray 儀表板,查看叢集狀態、任務執行與資源使用情況。

OpenShift 平台的安全性配置

OpenShift 作為企業級的 Kubernetes 發行版,在安全性方面有著更嚴格的預設設定。這些安全機制雖然提升了平台的整體安全性,卻也為 Ray 的部署帶來了額外的挑戰。理解 OpenShift 的安全模型與正確配置安全上下文,是成功部署 Ray 的關鍵。

OpenShift 的安全增強機制包含多個層面。Security Context Constraints 定義了 Pod 可以使用的安全特性,包括特權等級、存取的檔案系統路徑與可運行的使用者 UID。SELinux 提供了強制存取控制,限制程序對系統資源的存取。這些機制的預設配置相當保守,許多容器應用需要調整才能正常運行。

Ray 容器映像預設設定為以 UID 1000 的使用者身份運行。這個設計在一般的 Kubernetes 環境中沒有問題,但在 OpenShift 的 restricted SCC 下會遇到限制。restricted SCC 要求 Pod 使用隨機分配的 UID,不允許指定特定的使用者 ID。為了讓 Ray 能夠運行,需要使用 anyuid SCC,這個 SCC 允許容器以任意非 root 使用者身份運行。

# OpenShift 環境的 Ray 部署流程
# 首先確認已登入 OpenShift 叢集
oc login --server=https://api.cluster.example.com:6443

# 建立專案 (OpenShift 的命名空間)
oc new-project ray-system

# 建立 Service Account 用於 Ray Operator
oc create serviceaccount ray-operator-serviceaccount -n ray-system

# 將 Service Account 加入 anyuid SCC
# 這允許 Operator 以特定的 UID 運行
oc adm policy add-scc-to-user anyuid -z ray-operator-serviceaccount -n ray-system

# 安裝 Ray Operator CRD
oc apply -f https://raw.githubusercontent.com/ray-project/kuberay/v0.6.0/ray-operator/config/crd/bases/ray.io_rayclusters.yaml

# 建立 Operator Deployment
# 需要修改預設的 YAML 以使用正確的 Service Account
cat <<EOF | oc apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ray-operator
  namespace: ray-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ray-operator
  template:
    metadata:
      labels:
        app: ray-operator
    spec:
      # 使用有 anyuid 權限的 Service Account
      serviceAccountName: ray-operator-serviceaccount
      
      # 安全上下文設定
      securityContext:
        # 指定運行的使用者 UID
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
      
      containers:
      - name: operator
        image: rayproject/ray:2.7.0-py310
        command:
        - ray-operator
        env:
        - name: WATCH_NAMESPACE
          value: ""  # 空值表示監控所有命名空間
        
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi
EOF

# 驗證 Operator 是否正常運行
oc get pods -n ray-system
oc logs -n ray-system deployment/ray-operator

# 建立用於 Ray 叢集的 Service Account
oc create serviceaccount ray-node-serviceaccount -n ray-system

# 將 Service Account 加入 anyuid SCC
oc adm policy add-scc-to-user anyuid -z ray-node-serviceaccount -n ray-system

# 部署 Ray 叢集
# 注意必須在 Pod spec 中指定 Service Account
cat <<EOF | oc apply -f -
apiVersion: ray.io/v1alpha1
kind: RayCluster
metadata:
  name: ray-cluster
  namespace: ray-system
spec:
  rayVersion: '2.7.0'
  
  headGroupSpec:
    replicas: 1
    rayStartParams:
      dashboard-host: '0.0.0.0'
      port: '6379'
      num-cpus: '0'
    
    template:
      spec:
        # 使用有 anyuid 權限的 Service Account
        serviceAccountName: ray-node-serviceaccount
        
        # 安全上下文設定
        securityContext:
          runAsUser: 1000
          fsGroup: 1000
        
        containers:
        - name: ray-head
          image: rayproject/ray:2.7.0-py310
          
          # 容器級別的安全上下文
          securityContext:
            runAsUser: 1000
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
          
          ports:
          - containerPort: 6379
            name: gcs
          - containerPort: 8265
            name: dashboard
          
          resources:
            requests:
              cpu: "2"
              memory: "8Gi"
            limits:
              cpu: "4"
              memory: "16Gi"
  
  workerGroupSpecs:
  - replicas: 2
    minReplicas: 1
    maxReplicas: 5
    groupName: small-workers
    
    rayStartParams:
      num-cpus: '4'
    
    template:
      spec:
        serviceAccountName: ray-node-serviceaccount
        
        securityContext:
          runAsUser: 1000
          fsGroup: 1000
        
        containers:
        - name: ray-worker
          image: rayproject/ray:2.7.0-py310
          
          securityContext:
            runAsUser: 1000
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
          
          resources:
            requests:
              cpu: "4"
              memory: "16Gi"
            limits:
              cpu: "8"
              memory: "32Gi"
EOF

# 監控叢集啟動
oc get pods -n ray-system -w

# 建立 Route 暴露儀表板
# OpenShift 使用 Route 而非 Ingress
oc expose service ray-head-svc --name=ray-dashboard -n ray-system

# 查看 Route URL
oc get route ray-dashboard -n ray-system

# 測試叢集
oc run ray-test --image=rayproject/ray:2.7.0-py310 \
  --serviceaccount=ray-node-serviceaccount \
  --restart=Never \
  -n ray-system \
  -- python -c "
import ray
ray.init(address='ray-head-svc:10001')
print('Connected to Ray cluster')
print('Cluster resources:', ray.cluster_resources())
"

# 查看測試結果
oc logs ray-test -n ray-system

# 清理資源
oc delete raycluster ray-cluster -n ray-system
oc delete pod ray-test -n ray-system

這個完整的 OpenShift 部署流程展示了所有必要的安全性配置。Service Account 的建立與 SCC 的授權是關鍵步驟,缺少這些配置會導致 Pod 無法啟動。安全上下文的設定需要在多個層級進行,包括 Pod 層級與容器層級,確保所有元件都以正確的身份運行。

在生產環境中,安全性配置需要更加嚴格。除了基本的 UID 設定,還需要考慮網路政策、資源配額與 RBAC 權限。網路政策限制 Pod 之間的通訊,確保只有授權的連線能夠建立。資源配額防止單一叢集消耗過多資源,影響其他應用。RBAC 權限控制誰能夠建立與管理 Ray 叢集,實作職責分離。

Ray 分散式計算框架的跨平台部署展現了現代雲端原生應用的複雜性與靈活性。從 IBM Cloud 的虛擬機器部署到 Kubernetes 的容器編排,再到 OpenShift 的企業級安全性,每個平台都有其特點與挑戰。成功的部署需要深入理解平台特性,仔細規劃資源配置,並正確處理安全性要求。隨著組織對分散式運算需求的增長,掌握這些部署技術將成為雲端架構師與資料工程師的核心技能。透過自動化部署流程、標準化配置管理與持續監控最佳化,能夠建構穩定且高效的 Ray 運算平台,支撐企業的資料分析與機器學習應用。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。