Gunakan penjadwalan sadar topologi jaringan di kluster ACK Lingjun - Container Service for Kubernetes

Dalam skenario seperti pembelajaran mesin atau analisis data besar, pod sering kali memerlukan komunikasi yang intens. Secara default, penjadwal Kubernetes mendistribusikan pod secara merata di seluruh node dalam kluster Container Service for Kubernetes (ACK). Hal ini dapat menyebabkan latensi tinggi dalam komunikasi antar pod, sehingga meningkatkan waktu penyelesaian pekerjaan. Di kluster ACK Lingjun, penjadwalan sadar topologi jaringan dapat menetapkan pod ke domain forwarding Layer 1 atau Layer 2 yang sama, mengurangi latensi jaringan dan mempercepat penyelesaian pekerjaan.

Ikhtisar solusi

Penjadwalan sadar topologi jaringan menggunakan algoritma greedy untuk menetapkan tugas ke node Lingjun dengan rentang topologi minimal.

Misalkan kluster ACK Lingjun memiliki dua lapisan topologi jaringan: Pod dan Access Switch (ASW). ASW berfungsi sebagai antarmuka langsung untuk kluster Lingjun, sedangkan Pod mewakili topologi jaringan yang lebih luas. Transmisi antar node Lingjun memerlukan setidaknya satu hop pengalihan jaringan, sedangkan transmisi antar node ASW memerlukan setidaknya dua hop.

Untuk tugas yang membutuhkan dua node Lingjun, penjadwalan sadar topologi jaringan akan menetapkan tugas tersebut ke Node Pair A-B atau Node Pair E-F.
Untuk tugas yang membutuhkan empat node Lingjun, penjadwalan sadar topologi jaringan akan menetapkan tugas tersebut ke Node Pair A-D atau Node Pair E-H.

Untuk menentukan apakah node dalam kluster ACK Lingjun merupakan bagian dari ASW atau Pod yang sama, Anda dapat memeriksa label alibabacloud.com/asw-id dan alibabacloud.com/point-of-delivery. Label ini memberikan detail tentang lokasi jaringan.

Nyatakan struktur topologi

Untuk mengimplementasikan penjadwalan sadar topologi jaringan di kluster ACK Lingjun, definisikan persyaratan penjadwalan topologi tingkat kluster dan identifikasi informasi penjadwalan dalam tugas.

Buat file bernama cluster-network-topology.yaml untuk menyatakan struktur topologi dua tingkat.

Perluas untuk melihat template YAML lengkap

apiVersion: scheduling.koordinator.sh/v1alpha1
kind: ClusterNetworkTopology
metadata:
  # Tetap tidak berubah.
  name: default
spec:
  networkTopologySpec:
  # parentTopologyLayer digunakan untuk menyatakan struktur topologi atas.
  - parentTopologyLayer: ASWTopologyLayer
  # Saat Anda mendefinisikan topologi untuk node Lingjun, level terendah harus NodeTopologyLayer.
    topologyLayer: NodeTopologyLayer
  # Bagian berikut mendefinisikan topologi jaringan lintas lapisan. Biasanya, tidak diperlukan modifikasi.
  - labelKey:
    - alibabacloud.com/point-of-delivery
    topologyLayer: PoDTopologyLayer
  - labelKey:
    - alibabacloud.com/asw-id
    parentTopologyLayer: PoDTopologyLayer
    topologyLayer: ASWTopologyLayer

Buat file bernama sample-network-topology.yaml untuk menyatakan persyaratan penjadwalan sadar topologi jaringan untuk tugas.

Perluas untuk melihat template YAML lengkap

apiVersion: scheduling.koordinator.sh/v1alpha1
kind: JobNetworkTopology
metadata:
  labels:
    network-topology-permit-wait-time: "999999"
  # Nama tugas.
  name: sample-network-topology
  # Namespace tempat tugas berada.
  namespace: sample-network-topology
spec:
  topologyStrategy:
  # Konfigurasi ini memungkinkan penjadwalan lintas ASW.
  - layer: ASWTopologyLayer
    # Konfigurasi ini mendukung dua strategi: PreferGather dan MustGather. PreferGather memungkinkan penjadwalan pod lintas lapisan,
    # sementara MustGather membatasi penjadwalan pod dalam lapisan yang sama.
    strategy: PreferGather
  - layer: NodeTopologyLayer
    strategy: PreferGather
  # Tidak mengizinkan penjadwalan lintas pod.
  - layer: PoDTopologyLayer
    strategy: MustGather
  # Jumlah pod untuk tugas ini.
  workerNum: 2

Buat file bernama pi.yaml untuk menyatakan informasi penjadwalan sadar topologi jaringan.

Saat mengirimkan tugas, sertakan informasi JobNetworkTopology yang relevan.

Perluas untuk melihat template YAML lengkap

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  # Jumlah pod untuk tugas. Angka ini harus sesuai dengan angka di JobNetworkTopology.
  parallelism: 2
  template:
    metadata:
      labels:
        # Jumlah pod untuk tugas. Angka ini harus sesuai dengan angka di JobNetworkTopology.
        pod-group.scheduling.sigs.k8s.io/min-available: "2"
        pod-group.scheduling.sigs.k8s.io/name: sample-gang
        # Referensikan informasi topologi tugas yang baru saja dikirimkan.
        network-topology-job-name: sample-network-topology
        network-topology-job-namespace: sample-network-topology
    spec:
      schedulerName: default-scheduler
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
        resources:
          limits:
            # Contoh ini menggunakan satu GPU. Sesuaikan angka ini sesuai kebutuhan untuk kasus penggunaan sebenarnya.
            nvidia.com/gpu: 1
      restartPolicy: Never
  backoffLimit: 4

Jalankan perintah berikut untuk menerapkan file YAML di kluster:

kubectl apply -f cluster-network-topology.yaml
kubectl apply -f sample-network-topology.yaml
kubectl apply -f pi.yaml

Demonstrasi hasil penjadwalan

Gunakan kubectl untuk terhubung ke kluster dan ambil informasi topologi jaringan.

Di kluster ACK Lingjun, komponen lingjun-networktopology-collector mengumpulkan informasi ini dan melabelinya pada node Lingjun.

Untuk node lain atau jenis kluster yang berbeda, tambahkan label secara manual dan pastikan bahwa kunci label sesuai dengan labelKey yang ditentukan dalam ClusterNetworkTopology di template YAML sebelumnya.

# Topologi jaringan seperti:
#              test-pod-1                     test-pod-2
#        /          |           \                   |
#    test-1      test-2      test-3               test-4
#     /   \         |           |                   |
#   0.12  0.14     0.15        0.16                0.17

➜  network kubectl get no -l alibabacloud.com/asw-id,alibabacloud.com/point-of-delivery -ojson | jq '.items[] | {"Name":.metadata.name, "ASW":.metadata.labels."alibabacloud.com/asw-id", "POD":.metadata.labels."alibabacloud.com/point-of-delivery"}'
{
  "Name": "cn-hongkong.10.1.0.12",
  "ASW": "test-1",
  "POD": "test-pod-1"
}
{
  "Name": "cn-hongkong.10.1.0.14",
  "ASW": "test-1",
  "POD": "test-pod-1"
}
{
  "Name": "cn-hongkong.10.1.0.15",
  "ASW": "test-2",
  "POD": "test-pod-1"
}
{
  "Name": "cn-hongkong.10.1.0.16",
  "ASW": "test-3",
  "POD": "test-pod-1"
}
{
  "Name": "cn-hongkong.10.1.0.17",
  "ASW": "test-4",
  "POD": "test-pod-2"
}

Jalankan perintah berikut untuk mengirimkan tugas Job yang telah dikonfigurasi dan amati eksekusinya pada dua node Lingjun dalam test-1:

➜ kubectl get pod -owide
NAME       READY   STATUS              RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
pi-8p89l   1/1     Running             0          4s    172.30.240.197   cn-hongkong.10.1.0.14   <none>           <none>
pi-p8swv   0/1     ContainerCreating   0          4s    <none>           cn-hongkong.10.1.0.12   <none>           <none>

Jika Anda mengatur jumlah pod dalam tugas menjadi 4, perbarui parameter parallelism, pod-group.scheduling.sigs.k8s.io/min-available dalam file konfigurasi YAML untuk Job sebelumnya, serta parameter workerNum dalam file konfigurasi YAML untuk JobNetworkTopology sebelumnya.
Setelah melakukan modifikasi ini, Anda akan melihat bahwa hanya node Lingjun yang menjalankan test-pod-2 yang tetap tidak terjadwal.

➜ kubectl get pod -owide
NAME       READY   STATUS              RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
pi-2kwq9   1/1     Running             0          4s    172.30.241.123   cn-hongkong.10.1.0.12   <none>           <none>
pi-87hm5   0/1     ContainerCreating   0          4s    <none>           cn-hongkong.10.1.0.16   <none>           <none>
pi-bsvx8   1/1     Running             0          4s    172.30.240.198   cn-hongkong.10.1.0.14   <none>           <none>
pi-dvwhl   0/1     ContainerCreating   0          4s    <none>           cn-hongkong.10.1.0.15   <none>           <none>

Jika Anda mengatur jumlah pod dalam tugas menjadi 5, perbarui parameter parallelism, pod-group.scheduling.sigs.k8s.io/min-available dalam file konfigurasi YAML untuk Job sebelumnya, serta parameter workerNum dalam file konfigurasi YAML untuk JobNetworkTopology sebelumnya.

Setelah melakukan modifikasi ini, Anda akan melihat bahwa penjadwalan tugas gagal. Pod pertama yang dijadwalkan berisi pesan kegagalan penjadwalan all fail topology paths by MustGather reason: [path:RootNode->test-pod-1, freeSlotNum:4], [path:RootNode->DefaultTopologyName, freeSlotNum:0], [path:RootNode->test-pod-2, freeSlotNum:1]. Pesan ini menunjukkan bahwa penjadwalan gagal karena penjadwalan lintas pod tidak diizinkan.

➜ kubectl get pod
NAME       READY   STATUS    RESTARTS   AGE
pi-75qf5   0/1     Pending   0          2s
pi-8k4nd   0/1     Pending   0          2s
pi-b2pmc   0/1     Pending   0          2s
pi-n7c2b   0/1     Pending   0          2s
pi-wf4zn   0/1     Pending   0          2s


➜ kubectl get pod -ojson | jq '.items[].status'
{
  "conditions": [
    {
      "lastProbeTime": null,
      "lastTransitionTime": "2024-05-29T07:46:27Z",
      "message": "0/6 nodes are available: 1 Insufficient nvidia.com/gpu, 1 [NetworkTopology begin] cluster total nodes:6, 5 node provide 5 freeSlot, 1 node unavailable cause Insufficient nvidia.com/gpu, job desireNum:5, all fail topology paths by MustGather reason: [path:RootNode->test-pod-1, freeSlotNum:4], [path:RootNode->DefaultTopologyName, freeSlotNum:0], [path:RootNode->test-pod-2, freeSlotNum:1] [NetworkTopology end], 4 NetworkTopology bestPlan empty. network topology job sample-network-topology/sample-network-topology gets rejected due to pod is unschedulable, preemption: 0/6 nodes are available: 1 No victims found on node cn-hongkong.10.1.0.10 for preemptor pod pi-75qf5, 5 Preemption is not helpful for scheduling..",
      "reason": "Unschedulable",
      "status": "False",
      "type": "PodScheduled"
    }
  ],
  "phase": "Pending",
  "qosClass": "BestEffort"
}
{
  "phase": "Pending",
  "qosClass": "BestEffort"
}
{
  "phase": "Pending",
  "qosClass": "BestEffort"
}
{
  "phase": "Pending",
  "qosClass": "BestEffort"
}
{
  "phase": "Pending",
  "qosClass": "BestEffort"
}