Container Service for Kubernetes：Menempatkan layanan online dan aplikasi transkoding video secara bersamaan

Skenario penggunaan

Anda dapat menempatkan layanan NGINX online dan aplikasi transkoding video yang menggunakan FFmpeg secara bersamaan. Ini memungkinkan Anda memanfaatkan sumber daya yang dialokasikan ke pod tetapi tidak digunakan pada node. Anda dapat mengaktifkan fitur isolasi sumber daya dari ack-koordinator untuk mengisolasi sumber daya yang dialokasikan untuk layanan NGINX online dari sumber daya yang dialokasikan untuk aplikasi transkoding video yang menggunakan FFmpeg. Dengan cara ini, kinerja layanan NGINX online dapat dijamin.

Arsitektur penyebaran penempatan bersama

Dalam contoh ini, layanan NGINX online dan aplikasi transkoding video yang menggunakan FFmpeg ditempatkan pada node yang sama. Kelas Kualitas Layanan (QoS) dari pod yang dibuat untuk layanan NGINX diatur ke sensitif-latensi (LS). Kelas QoS dari pod yang dibuat untuk aplikasi transkoding video diatur ke usaha-terbaik (BE). Dalam topik ini, layanan NGINX diterapkan dalam mode penempatan bersama yang berbeda untuk menguji kinerja layanan NGINX.

Persiapan

Mengatur lingkungan

• Tambahkan dua node ke kluster ACK Pro. Salah satu node menjalankan layanan web NGINX dan aplikasi transkoding video yang menggunakan FFmpeg, serta berfungsi sebagai mesin yang diuji. Node lainnya memiliki alat wrk terinstal dan digunakan untuk melakukan uji stres dengan mengirimkan permintaan ke layanan NGINX. Untuk informasi lebih lanjut, lihat Buat Kluster ACK Pro.

• Untuk memaksimalkan manfaat yang diberikan oleh kemampuan penempatan bersama dari ack-koordinator, kami sarankan Anda menerapkan mesin yang diuji pada Elastic Compute Service (ECS) Bare Metal Instance dan menggunakan Alibaba Cloud Linux sebagai sistem operasi node.

• Instal ack-koordinator (sebelumnya dikenal sebagai ack-slo-manager) dan aktifkan kebijakan penempatan bersama. Untuk informasi lebih lanjut, lihat Memulai. Dalam contoh ini, ack-koordinator versi 0.8.0 digunakan.

Menyebarkan layanan NGINX online

Sebarkan layanan NGINX online dan wrk.

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

   Tampilkan Isi File YAML

   ---
   # Contoh konfigurasi NGINX.
   apiVersion: v1
   data:
     config: |-
       user  nginx;
       worker_processes  80; # Jumlah proses pekerja yang berjalan di layanan NGINX. Parameter ini menentukan jumlah permintaan yang dapat diproses secara bersamaan oleh server NGINX.
   
       events {
           worker_connections  1024;  # Jumlah koneksi pekerja. Nilai default: 1024.
       }
   
       http {
           server {
               listen  8000;
   
               gzip off;
               gzip_min_length 32;
               gzip_http_version 1.0;
               gzip_comp_level 3;
               gzip_types *;
           }
       }
   
       #daemon off;
   kind: ConfigMap
   metadata:
     name: nginx-conf
   
   ---
   # Pod yang menjalankan layanan NGINX online.
   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: '80'
             memory: 10Gi
           requests:
             cpu: '80'
             memory: 10Gi
         volumeMounts:
           - mountPath: /apps/nginx/conf
             name: config
     hostNetwork: true
     restartPolicy: Never
     volumes:
       - configMap:
           items:
             - key: config
               path: nginx.conf
           name: nginx-conf
         name: config
     nodeName: cn-beijing.192.168.2.93  # Ganti nilai ini dengan nama node dari mesin yang diuji.

2. Jalankan perintah berikut untuk menerapkan layanan NGINX:

   kubectl apply -f ls-nginx.yaml

3. Jalankan perintah berikut untuk menanyakan nama pod yang menjalankan layanan NGINX:

   kubectl get pod -l app=nginx -o wide

   Keluaran yang Diharapkan:

   NAME    READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   nginx   1/1     Running   0          43s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

   Keluaran menunjukkan bahwa pod berada dalam status Running. Ini menunjukkan bahwa layanan NGINX berjalan sesuai harapan pada mesin yang diuji.

4. Jalankan perintah berikut di node lain untuk menerapkan wrk:

   wget -O wrk-4.2.0.tar.gz https://github.com/wg/wrk/archive/refs/tags/4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
   cd wrk-4.2.0 && make && chmod +x ./wrk

Menyebarkan aplikasi transkoding video offline

Sebarkan aplikasi transkoding video offline yang menggunakan FFmpeg.

1. Buat file YAML bernama be-ffmpeg.yaml dan salin konten berikut ke dalam file tersebut:

   Tampilkan Isi File YAML

   # Pod yang menjalankan aplikasi transkoding video offline yang menggunakan FFmpeg.
   apiVersion: v1
   kind: Pod
   metadata:
     name: be-ffmpeg
     labels:
       app: ffmpeg
     # 1. Gunakan mode penempatan bersama default Kubernetes untuk menerapkan aplikasi: Hapus label koordinator.sh/qosClass=BE.
     # 2. Gunakan mode penempatan bersama yang sadar SLO dari ACK untuk menerapkan aplikasi: Pertahankan label koordinator.sh/qosClass=BE.
       koordinator.sh/qosClass: BE
   spec:
     containers:
       # Anda dapat meningkatkan jumlah proses dalam pod untuk meningkatkan pemanfaatan sumber daya aplikasi transkoding video offline. Jumlah default adalah 25. Setiap proses berisi dua utas yang berjalan secara paralel.
       - command:
           - start-ffmpeg.sh
           - '25'
           - '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:
         # 1. Gunakan mode penempatan bersama default Kubernetes untuk menerapkan aplikasi: Hapus sumber daya ekstensi berikut: kubernetes.io/batch-cpu dan kubernetes.io/batch-memory.
         # 2. Gunakan mode penempatan bersama yang sadar SLO dari ACK untuk menerapkan aplikasi: Pertahankan sumber daya ekstensi berikut: kubernetes.io/batch-cpu dan kubernetes.io/batch-memory.
         # Tentukan permintaan sumber daya berdasarkan spesifikasi sumber daya node.
           limits:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
           requests:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
     hostNetwork: true
     restartPolicy: Never
     nodeName: cn-beijing.192.168.2.93  # Ganti nilai ini dengan nama node dari mesin yang diuji.

2. Jalankan perintah berikut untuk menerapkan aplikasi transkoding video yang menggunakan FFmpeg:

   kubectl apply -f be-ffmpeg.yaml

3. Jalankan perintah berikut untuk menanyakan status pod tempat aplikasi transkoding video yang menggunakan FFmpeg berjalan:

   kubectl get pod -l app=ffmpeg -o wide

   Keluaran yang Diharapkan:

   NAME        READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   be-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

   Keluaran menunjukkan bahwa pod berada dalam status Running. Ini menunjukkan bahwa aplikasi transkoding video yang menggunakan FFmpeg berjalan sesuai harapan pada mesin yang diuji.

Prosedur

Dalam topik ini, layanan online dan aplikasi offline diterapkan dalam tiga mode penempatan bersama untuk menguji kinerja aplikasi dan pemanfaatan sumber daya node dalam mode-mode ini. Tabel berikut membandingkan mode-mode ini dalam hal kinerja aplikasi dan pemanfaatan sumber daya node.

Hasil pengujian

• Bandingkan metrik kelompok kontrol dengan metrik kelompok dasar: Rata-rata pemanfaatan CPU node meningkat dari 29.6% menjadi 65.1%. Nilai NGINX RT-P90 dan NGINX RT-P99 meningkat secara signifikan. Kurva RT memiliki ekor panjang.

• Bandingkan metrik kelompok eksperimen dengan metrik kelompok dasar: Rata-rata pemanfaatan CPU node meningkat dari 28.5% menjadi 64.8%. Nilai NGINX RT-P90 dan NGINX RT-P99 meningkat sedikit.

• Bandingkan metrik kelompok eksperimen dengan metrik kelompok kontrol: Rata-rata pemanfaatan CPU node serupa. Nilai NGINX RT-P90 dan NGINX RT-P99 menurun secara signifikan dan mendekati nilai NGINX RT-P90 dan NGINX RT-P99 kelompok dasar.

Hasil di atas menunjukkan bahwa mode penempatan bersama yang sadar SLO dari ACK dapat secara efektif meningkatkan pemanfaatan CPU node dan mengurangi gangguan kinerja ketika layanan NGINX online dan aplikasi transkoding video offline diterapkan pada node yang sama.

Menyebarkan aplikasi

Exclusive deployment mode of the online service

Terapkan hanya layanan online pada mesin yang diuji.

1. Lihat bagian Menyebarkan Layanan NGINX Online dari topik ini untuk menerapkan layanan NGINX online pada mesin yang diuji.

2. Gunakan wrk untuk mengirimkan permintaan ke layanan NGINX.

   # Ganti node_ip dengan alamat IP mesin yang diuji. Port 8000 layanan NGINX diekspos ke mesin yang diuji.
   ./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

3. Jalankan perintah berikut untuk menanyakan rata-rata pemanfaatan CPU mesin yang diuji:

   kubectl top node

   Keluaran yang Diharapkan:

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.192.168.2.93   29593m       29%    xxxx            xxxx
   cn-beijing.192.168.2.94   6874m        7%     xxxx            xxxx

   Keluaran menunjukkan bahwa rata-rata pemanfaatan CPU mesin yang diuji sekitar 29%.

4. Setelah uji stres selesai, jalankan perintah berikut untuk menanyakan hasil pengujian dari wrk:

   Untuk mendapatkan hasil pengujian yang akurat, kami sarankan Anda melakukan beberapa uji stres.

   Running 1m test @ http://192.168.2.94:8000/

   Keluaran yang Diharapkan:

     6 threads and 54 connections
     Thread Stats   Avg      Stdev     Max   +/- Stdev
       Latency   402.18us    1.07ms  59.56ms   99.83%
       Req/Sec    24.22k     1.12k   30.58k    74.15%
     Latency Distribution
        50%  343.00us
        75%  402.00us
        90%  523.00us
        99%  786.00us
     8686569 requests in 1.00m, 6.88GB read
   Requests/sec: 144537.08
   Transfer/sec:    117.16MB

   RT adalah metrik kunci untuk mengevaluasi kinerja layanan NGINX online dalam skenario yang berbeda. Dalam keluaran, bagian Latency Distribution menunjukkan distribusi nilai persentil RT. Misalnya, 90% 523.00us menunjukkan bahwa RT untuk memproses 90% permintaan adalah 523.00 mikrodetik. Ketika hanya layanan NGINX online yang diterapkan, RT-P50 adalah 343 mikrodetik, RT-P90 adalah 523 mikrodetik, dan RT-P99 adalah 786 mikrodetik.

Default colocation mode of Kubernetes

Tempatkan layanan NGINX online dan aplikasi transkoding video offline yang menggunakan FFmpeg pada mesin yang diuji. Kemudian, gunakan wrk untuk mengirimkan permintaan ke layanan NGINX. Lihat bagian Mode Penempatan Bersama yang Sadar SLO dari ACK dari topik ini untuk menempatkan aplikasi secara bersamaan. Anda harus mengonfigurasi parameter dan anotasi berdasarkan persyaratan dalam template YAML.

SLO-aware colocation mode of ACK

Atur kelas QoS aplikasi transkoding video yang menggunakan FFmpeg menjadi BE.

1. Lihat topik Memulai untuk mengaktifkan penempatan bersama yang sadar SLO.

   Daftar berikut menjelaskan fitur-fitur yang terkait dengan penempatan bersama yang sadar SLO:

   • Aktifkan Overcommit Sumber Daya Dinamis: Setelah Anda mengaktifkan fitur ini, gunakan konfigurasi default. Fitur ini memungkinkan sistem untuk melakukan overcommit terhadap sumber daya yang dialokasikan ke pod tetapi tidak digunakan pada node, lalu menjadwalkan sumber daya yang diovercommit ke pod BE.

   • Aktifkan Penekanan CPU: Setelah Anda mengaktifkan fitur ini, atur parameter cpuSuppressThresholdPercent menjadi 65 dan gunakan pengaturan default untuk konfigurasi lainnya. Fitur ini dapat membatasi penggunaan CPU pod BE ketika pemanfaatan CPU node melebihi 65%. Ini memastikan kinerja pod LS.

   • Aktifkan CPU QoS untuk Kontainer: Setelah Anda mengaktifkan fitur ini, gunakan konfigurasi default. Fitur ini memungkinkan Anda mengaktifkan kemampuan CPU Identity dari Alibaba Cloud Linux. Dengan cara ini, pod LS diprioritaskan daripada pod BE selama penjadwalan CPU. Ini mencegah pod BE memengaruhi pod LS ketika Simultaneous Multithreading (SMT) digunakan untuk menjalankan utas kedua pod secara bersamaan.

   • Aktifkan Isolasi Sumber Daya Berdasarkan Cache L3 dan MBA: Setelah Anda mengaktifkan fitur ini, gunakan konfigurasi default. Fitur ini memungkinkan Anda mengisolasi cache L3 (last level cache) dan bandwidth memori pada instance ECS Bare Metal. Dengan cara ini, pod LS diprioritaskan untuk menggunakan cache L3 dan bandwidth memori.

   Penting

   • Fitur CPU QoS hanya dapat diaktifkan ketika Alibaba Cloud Linux digunakan sebagai OS node.

   • Isolasi cache L3 dan bandwidth memori hanya dapat diaktifkan ketika node diterapkan pada instance ECS Bare Metal.

2. Lihat bagian Menyebarkan Layanan NGINX Online dari topik ini untuk menerapkan aplikasi NGINX online pada mesin yang diuji.

3. Buat file YAML bernama be-ffmpeg.yaml dan salin konten berikut ke dalam file tersebut:

   Tampilkan Isi File YAML

   # Pod yang menjalankan aplikasi transkoding video offline yang menggunakan FFmpeg.
   apiVersion: v1
   kind: Pod
   metadata:
     name: be-ffmpeg
     labels:
       app: ffmpeg
     labels:
       # Atur kelas QoS aplikasi transkoding video yang menggunakan FFmpeg menjadi BE.
       koordinator.sh/qosClass: BE
   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:
         # Ajukan permohonan untuk sumber daya berikut yang diovercommit secara dinamis: kubernetes.io/batch-cpu dan kubernetes.io/batch-memory.
           limits:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
           requests:
             kubernetes.io/batch-cpu: 70k
             kubernetes.io/batch-memory: 22Gi
     hostNetwork: true
     restartPolicy: Never
     nodeName: cn-beijing.192.168.2.93  # Ganti nilai ini dengan nama node dari mesin yang diuji.

4. Jalankan perintah berikut untuk menerapkan aplikasi transkoding video yang menggunakan FFmpeg:

   kubectl apply -f besteffort-ffmpeg.yaml

5. Jalankan perintah berikut untuk menanyakan status pod yang dibuat untuk cert-manager:

   kubectl get pod -l app=ffmpeg -o wide

   Keluaran yang Diharapkan:

   NAME                READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
   besteffort-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

6. Jalankan perintah berikut untuk mengirimkan permintaan ke layanan NGINX menggunakan wrk:

   # Ganti node_ip dengan alamat IP mesin yang diuji. Port 8000 layanan NGINX diekspos ke mesin yang diuji.
   ./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

7. Jalankan perintah berikut untuk menanyakan pemanfaatan CPU mesin yang diuji:

   kubectl top node

   Keluaran yang Diharapkan:

   NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   cn-beijing.192.168.2.93   65424m       63%    xxxx            xxxx
   cn-beijing.192.168.2.94   7040m        7%     xxxx            xxxx

   Keluaran menunjukkan bahwa pemanfaatan CPU mesin yang diuji sekitar 63%.

8. Setelah uji stres selesai, jalankan perintah berikut untuk mencetak hasil pengujian dari wrk:

   Untuk informasi lebih lanjut tentang hasil pengujian, lihat bagian Hasil Pengujian dari topik ini.

Pertanyaan Umum

Apa yang harus saya lakukan jika hasil uji stres yang dikembalikan oleh wrk menampilkan "Socket errors: connect 54,"?

Problem description

Hasil uji stres yang dikembalikan oleh wrk menampilkan Socket errors: connect 54,. Koneksi antara klien wrk dan server NGINX gagal dibuat. Akibatnya, uji stres gagal.

Cause

Kesalahan ini terjadi ketika jumlah koneksi klien melebihi batas atas. Akibatnya, klien gagal membuat koneksi ke server NGINX.

Solution

Untuk mencegah kesalahan ini, periksa pengaturan koneksi TCP pada mesin uji stres dan aktifkan fitur penggunaan ulang koneksi TCP.

1. Masuk ke mesin uji stres dan jalankan perintah berikut untuk memeriksa apakah penggunaan ulang koneksi TCP diaktifkan:

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   Jika 0 atau 2 dikembalikan, fitur penggunaan ulang koneksi TCP dinonaktifkan.

2. Jalankan perintah berikut untuk mengaktifkan fitur penggunaan ulang koneksi TCP:

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. Gunakan wrk untuk memulai uji stres lainnya.

   Jika hasil uji stres tidak menampilkan Socket errors: connect 54, ..., uji stres berhasil.