全部产品
Search
文档中心

Container Service for Kubernetes:Memulai

更新时间:Jul 06, 2025

Topik ini menjelaskan cara menggunakan ack-koordinator untuk membangun lingkungan colocation bagi beban kerja sensitif latensi (LS) dan best-effort (BE). Topik ini juga mencakup langkah-langkah untuk mengkocolokasi aplikasi Anda.

Prasyarat

Prioritas sumber daya dan QoS

Prioritas sumber daya dan Kelas Kualitas Layanan (QoS) adalah konsep utama dari fitur colocation berbasis tujuan tingkat layanan (SLO) yang disediakan oleh ACK.

Prioritas sumber daya digunakan untuk membatasi jenis-jenis sumber daya pada sebuah node. Prioritas ini membantu menyelesaikan masalah rendahnya pemanfaatan sumber daya meskipun alokasi meningkat. Tabel berikut menjelaskan perbedaan antara prioritas sumber daya.

  • Jumlah sumber daya prioritas rendah bergantung pada jumlah sumber daya prioritas tinggi yang diminta dan digunakan oleh pod. Sebagai contoh, sumber daya Produk yang dialokasikan tetapi tidak digunakan diturunkan menjadi sumber daya Batch dan kemudian dialokasikan ulang.

  • Cara menetapkan prioritas sumber daya memengaruhi jumlah sumber daya kluster yang dapat dioverkomit serta ketersediaan sumber daya pada node.

  • Sumber daya untuk overcommitment dideskripsikan dan diperbarui sebagai sumber daya ekstensi standar dalam metadata node.

Tabel berikut menjelaskan prioritas sumber daya yang digunakan dalam ACK.

Prioritas sumber daya

Kalkulasi jumlah sumber daya

Nama sumber daya

Produk

Biasanya, jumlah sumber daya Produk sama dengan jumlah sumber daya fisik yang disediakan oleh node.

Sumber daya yang dapat dialokasikan pada node, termasuk sumber daya CPU dan memori.

Batch

Jumlah sumber daya Batch sama dengan jumlah sumber daya yang dioverkomit, yang dihitung secara dinamis berdasarkan pemanfaatan sumber daya node. Jumlah sumber daya untuk overcommitment dihitung berdasarkan rumus berikut: Jumlah sumber daya untuk overcommitment = Total jumlah sumber daya fisik pada node - Jumlah sumber daya Produk yang digunakan. Untuk informasi lebih lanjut, lihat Overkomitmen sumber daya dinamis.

Sumber daya Batch dideskripsikan dan diperbarui sebagai sumber daya ekstensi dalam metadata node dengan menggunakan parameter kubernetes.io/batch-cpu dan kubernetes.io/batch-memory.

Kelas QoS menggambarkan sensitivitas sumber daya aplikasi. Pod yang ditugaskan ke kelas QoS berbeda beroperasi pada tingkat performa yang berbeda untuk memenuhi SLO yang berbeda. Kelas QoS yang berbeda sesuai dengan parameter isolasi sumber daya yang berbeda. Ketika sumber daya pada node tidak mencukupi, sumber daya akan dialokasikan terlebih dahulu ke pod dengan kelas QoS prioritas tinggi. Tabel berikut menjelaskan kelas QoS yang digunakan dalam ACK.

Kelas QoS

Beban kerja yang berlaku

Deskripsi

LS (Latency Sensitive)

Layanan online (beban kerja LS)

Beban kerja LS diprioritaskan dalam penjadwalan irisan waktu CPU dan alokasi sumber daya memori, termasuk cache L3 (last level cache) dan sumber daya bandwidth memori. Sistem lebih memilih mereklaim memori dari beban kerja BE dan menyimpan sumber daya memori untuk beban kerja LS ketika reklamasi memori dipicu.

BE (Best Effort)

Pekerjaan intensif sumber daya (beban kerja BE)

Beban kerja BE memiliki prioritas lebih rendah daripada beban kerja LS dalam penjadwalan irisan waktu CPU. Sumber daya cache L3 dan bandwidth memori yang dapat digunakan oleh beban kerja BE dibatasi. Dibandingkan dengan beban kerja LS, sistem lebih memilih mereklaim memori dari beban kerja BE ketika reklamasi memori dipicu.

Prioritas sumber daya dan kelas QoS independen satu sama lain namun dapat digunakan sebagai kombinasi. Namun, karena batasan model colocation dan persyaratan bisnis, hanya kombinasi berikut yang digunakan:

  • Produk + LS: Kombinasi ini cocok untuk aplikasi online yang memerlukan latensi rendah dan harus diprioritaskan selama alokasi sumber daya, seperti aplikasi web dan pekerjaan komputasi aliran yang sensitif terhadap latensi.

  • Batch + BE: Kombinasi ini cocok untuk aplikasi offline yang memiliki prioritas lebih rendah daripada aplikasi online dalam alokasi sumber daya, seperti pekerjaan Spark batch, pekerjaan MapReduce batch, dan pekerjaan pelatihan AI.

Kelola kebijakan colocation

ACK menyediakan ConfigMap yang dapat digunakan untuk mengelola kebijakan colocation dari ack-koordinator. Untuk mengaktifkan semua kebijakan colocation dari ack-koordinator, ikuti langkah-langkah berikut:

  1. Buat file bernama configmap.yaml berdasarkan isi ConfigMap berikut:

    # Contoh ConfigMap ack-slo-config. 
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ack-slo-config
      namespace: kube-system
    data:
      colocation-config: |-
        {
          "enable": true
        }
      resource-qos-config: |-
        {
          "clusterStrategy": {
            "lsClass": {
              "cpuQOS": {
                "enable": true
              },
              "memoryQOS": {
                "enable": true
              },
              "resctrlQOS": {
                "enable": true
              }
            },
            "beClass": {
              "cpuQOS": {
                "enable": true
              },
              "memoryQOS": {
                "enable": true
              },
              "resctrlQOS": {
                "enable": true
              }
            }
          }
        }
      resource-threshold-config: |-
        {
          "clusterStrategy": {
            "enable": true
          }
        }

    Tabel berikut menjelaskan parameter yang menentukan kebijakan colocation yang berbeda dalam contoh sebelumnya.

    Parameter

    Deskripsi

    colocation-config

    Ketika kebijakan ini ditentukan, ack-slo-config mengumpulkan data pemantauan waktu nyata tentang beban node dan kemudian menganalisis data pemantauan untuk mengidentifikasi sumber daya yang dapat dioverkomit. Jika sumber daya dialokasikan ke pod tetapi tidak digunakan, sumber daya tersebut dapat dioverkomit. Untuk informasi lebih lanjut, lihat Overkomitmen sumber daya dinamis.

    resource-qos-config

    Ketika kebijakan ini ditentukan, ack-slo-config mengelola berbagai jenis sumber daya secara halus dan memastikan bahwa sumber daya lebih disukai dialokasikan ke pod dengan kelas QoS prioritas tinggi. Untuk informasi lebih lanjut, lihat CPU QoS, Memory QoS untuk kontainer, dan Isolasi sumber daya berdasarkan cache L3 dan MBA.

    resource-threshold-config

    Ketika kebijakan ini ditentukan, ack-slo-config secara dinamis membatasi sumber daya yang dapat digunakan oleh pod dengan kelas QoS prioritas rendah berdasarkan watermark pemanfaatan sumber daya node. Untuk informasi lebih lanjut, lihat Batas sumber daya elastis.

  2. Jalankan perintah berikut untuk membuat ConfigMap:

    kubectl apply -f configmap.yaml

Terapkan aplikasi

  1. Buat file bernama nginx-ls-pod.yaml dan salin konten berikut ke file tersebut:

    Tetapkan kelas QoS aplikasi sensitif latensi ke LS. Dalam contoh ini, koordinator.sh/qosClass: LS ditentukan di bagian labels dalam konfigurasi pod yang dibuat untuk aplikasi NGINX.

    # Contoh file nginx-ls-pod.yaml. 
    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        koordinator.sh/qosClass: LS
        app: nginx
      name: nginx
    spec:
      containers:
        - image: 'koordinatorsh/nginx:v1.18-koord-exmaple'
          imagePullPolicy: IfNotPresent
          name: nginx
          ports:
            - containerPort: 8000
              hostPort: 8000 # Port yang digunakan untuk melakukan uji stres. 
              protocol: TCP
          resources:
            limits:
              cpu: '8'
              memory: 1Gi
            requests:
              cpu: '8'
              memory: 1Gi
          volumeMounts:
            - mountPath: /apps/nginx/conf
              name: config
      hostNetwork: true
      restartPolicy: Never
      volumes:
        - configMap:
            items:
              - key: config
                path: nginx.conf
            name: nginx-conf
          name: config
  2. Buat file bernama ffmpeg-be-pod.yaml dan salin konten berikut ke file tersebut:

    Tetapkan kelas QoS aplikasi intensif sumber daya ke BE dan konfigurasikan overkomitmen sumber daya dengan menentukan parameter kubernetes.io/batch-cpu dan kubernetes.io/batch-memory. Dalam contoh ini, koordinator.sh/qosClass: BE ditentukan di bagian labels dalam konfigurasi pod yang dibuat untuk aplikasi transkoding.

    # Contoh file ffmpeg-be-pod.yaml. 
    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        koordinator.sh/qosClass: BE
      name: be-ffmpeg
    spec:
      containers:
        - command:
            - start-ffmpeg.sh
            - '30'
            - '2'
            - /apps/ffmpeg/input/HD2-h264.ts
            - /apps/ffmpeg/
          image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
          imagePullPolicy: Always
          name: ffmpeg
          resources:
            limits:
              # Unit: millicores. 
              kubernetes.io/batch-cpu: "70k"
              kubernetes.io/batch-memory: "22Gi"
            requests:
              # Unit: millicores. 
              kubernetes.io/batch-cpu: "70k"
              kubernetes.io/batch-memory: "22Gi"
  3. Jalankan perintah berikut untuk menerapkan pod untuk aplikasi sensitif latensi dan aplikasi intensif sumber daya:

    kubectl apply -f nginx-ls-pod.yaml
    kubectl apply -f ffmpeg-be-pod.yaml

Apa yang harus dilakukan selanjutnya

Setelah aplikasi diterapkan, Anda dapat menggunakan fitur colocation yang disediakan oleh ACK. Untuk informasi lebih lanjut, lihat Kolokasi layanan online dan aplikasi transkoding video.