Container Service for Kubernetes：FAQ kelompok node

Indeks

Untuk mendiagnosis dan menangani masalah node, lihat Troubleshoot node exceptions.

Bagaimana cara menggunakan spot instance dalam kelompok node?

Dapatkah saya mengonfigurasi berbagai tipe instans ECS dalam satu kelompok node?

Ya, Anda bisa. Untuk mencegah kegagalan skala keluar akibat ketidaktersediaan instans atau kekurangan stok, kami merekomendasikan strategi berikut:

• Konfigurasikan beberapa vSwitch untuk kelompok node di berbagai zona ketersediaan.

• Pilih beberapa tipe instans Elastic Compute Service (ECS) atau tentukan tipe instans berdasarkan spesifikasi vCPU dan memori.
  Anda dapat melihat tingkat skalabilitas kelompok node setelah pembuatan.

Untuk tipe instans yang tidak didukung dan rekomendasi konfigurasi node, lihat ECS instance type configuration recommendations.

Bagaimana cara menghitung jumlah maksimum pod per node?

Jumlah maksimum pod yang didukung per node bergantung pada plugin jaringan yang digunakan oleh kluster. Untuk metode perhitungan detail, lihat Maximum number of pods per node.

• Terway: Max pods per node = Pod berbasis Elastic Network Interface (ENI) maksimum + Pod jaringan host.

• Flannel: Batasnya ditentukan oleh Number of Pods per Node yang ditentukan saat pembuatan kluster.

Anda dapat melihat jumlah maksimum pod, yaitu Pod Quota, di daftar node pada halaman Nodes di konsol ACK.

Bagaimana cara menyesuaikan kapasitas pod ketika node mencapai batas pod-nya?

Jumlah maksimum pod yang didukung oleh satu node pekerja ditentukan oleh jenis plugin jaringan dan umumnya tidak dapat diubah.

• Mode Terway: Jumlah maksimum pod per node bergantung pada jumlah ENI yang disediakan oleh instans ECS.

• Mode Flannel: Jumlah maksimum pod per node ditentukan saat pembuatan kluster dan tidak dapat diubah setelah ditetapkan.

Jika jumlah pod di kluster Anda mencapai batasnya, kami merekomendasikan memperluas kapasitas kelompok node untuk menambahkan lebih banyak node, sehingga meningkatkan total kapasitas pod yang tersedia di kluster Anda. Untuk informasi lebih lanjut, lihat Increase the maximum number of pods in a cluster.

Bagaimana cara memodifikasi konfigurasi node?

Untuk memastikan stabilitas kluster, parameter tertentu—khususnya yang terkait dengan jaringan dan ketersediaan tinggi—bersifat immutable setelah kelompok node dibuat. Misalnya, Anda tidak dapat mengubah runtime kontainer atau virtual private cloud (VPC) tempat node berada.

Untuk parameter yang dapat diubah, perubahan biasanya hanya berlaku untuk node yang baru dibuat. Node yang sudah ada tidak terpengaruh kecuali dinyatakan lain (seperti Update ECS Tags of Existing Nodes dan Update Labels and Taints of Existing Nodes).

Praktik terbaik untuk menerapkan konfigurasi baru:
Untuk menerapkan pengaturan baru ke node yang sudah ada, ikuti langkah-langkah berikut:

1. Buat kelompok node baru dengan konfigurasi yang diinginkan.

2. Cordon dan drain node di kelompok node lama untuk memigrasikan workload ke node baru.

3. Setelah migrasi selesai, lepaskan instans di kelompok node lama.

Untuk informasi lebih lanjut tentang parameter mana yang dapat dimodifikasi dan kapan perubahan tersebut berlaku, lihat Edit a node pool.

Dapatkah saya menonaktifkan fitur Expected Nodes?

Jika Scaling Mode kelompok node diatur ke Manual, parameter Expected Nodes bersifat wajib dan tidak dapat dinonaktifkan.

Jika Anda ingin menghapus atau melepaskan node tertentu, lihat Remove a node. Jika Anda ingin menambahkan node tertentu, lihat Add an existing node. Setelah Anda menghapus node atau menambahkan node yang ada, jumlah instans yang diharapkan secara otomatis disesuaikan menjadi jumlah node baru. Anda tidak perlu mengubahnya secara manual.

Apa perbedaan antara kelompok node dengan dan tanpa Expected Nodes yang diaktifkan?

Parameter Expected Nodes menentukan kapasitas yang diinginkan dari kelompok node. Anda dapat memperluas atau mempersempit kelompok node dengan menyesuaikan parameter ini. Meskipun sebagian besar kelompok node modern menggunakan fitur ini untuk rekonsiliasi dan penskalaan, beberapa kelompok node lama mungkin tidak memiliki fitur ini diaktifkan.

Tabel berikut menjelaskan bagaimana sistem merespons operasi berbeda berdasarkan pengaturan ini:

Bagaimana cara menambahkan node bebas ke kelompok node?

Node pekerja yang dibuat di kluster lama sebelum pengenalan fitur kelompok node dianggap sebagai node bebas. Jika Anda tidak lagi membutuhkannya, lepaskan instans ECS yang sesuai. Namun, jika ingin memanfaatkan manajemen kelompok dan O&M otomatis, kami merekomendasikan untuk memigrasikannya ke kelompok node.

Buat kelompok node baru atau perluas yang sudah ada, hapus node bebas dari kluster, lalu tambahkan ke kelompok node target. Untuk detailnya, lihat Add free nodes to a node pool.

Bagaimana cara mengubah citra OS kelompok node?

Anda dapat mengganti OS sesuai kebutuhan. Misalnya, dari CentOS ke Alibaba Cloud Linux atau meningkatkan ke versi yang lebih baru dari OS saat ini. Sebelum melanjutkan, tinjau catatan rilis citra OS untuk kompatibilitas dan batasan penggunaan.

Untuk petunjuk langkah demi langkah, lihat Replace the OS of a node pool.

Bagaimana cara melepaskan Instance ECS tertentu?

Untuk melepaskan Instance ECS tertentu, Anda harus menghapus node melalui konsol ACK. Ini memastikan jumlah Expected Nodes diperbarui secara otomatis dan benar tanpa intervensi manual. Hanya dengan mengurangi jumlah Expected Nodes akan memicu scale-in acak, yang mungkin tidak menargetkan instans spesifik yang ingin Anda lepaskan.

Apa yang harus saya lakukan jika penambahan node yang ada gagal dengan error timeout?

1. Periksa konektivitas: Pastikan node memiliki akses jaringan ke instans Classic Load Balancer (CLB) API server.

2. Security group: Verifikasi bahwa aturan Security Group mengizinkan traffic yang diperlukan. Lihat Security group limits untuk menambahkan node yang ada.

3. Jaringan umum: Untuk masalah yang lebih kompleks, lihat Network management FAQ.

Bagaimana cara mengubah hostname node pekerja di kluster ACK?

Kemudian, lakukan langkah-langkah berikut:

1. Hapus node dari kluster.

2. Tambahkan kembali node yang dihapus ke kelompok node. Untuk petunjuknya, lihat Manually add nodes.

   Node akan secara otomatis diganti namanya saat bergabung kembali ke kluster berdasarkan templat penamaan kelompok node.

Bagaimana cara memperbarui kernel dan driver NVIDIA secara manual pada node GPU?

1. Hubungkan ke kluster: Dapatkan kubeconfig kluster dan gunakan kubectl untuk menghubungkan ke kluster.

2. Cordon node: Cegah penjadwalan pod baru pada node GPU target. Contoh ini menggunakan node cn-beijing.i-2ze19qyi8votgjz*****.

   kubectl cordon cn-beijing.i-2ze19qyi8votgjz*****
   
   node/cn-beijing.i-2ze19qyi8votgjz***** already cordoned

3. Drain node: Pindahkan pod yang ada ke node lain.

   kubectl drain cn-beijing.i-2ze19qyi8votgjz***** --grace-period=120 --ignore-daemonsets=true
   
   node/cn-beijing.i-2ze19qyi8votgjz***** cordoned
   WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg
   pod/nginx-ingress-controller-78d847fb96-***** evicted

4. Uninstal driver NVIDIA saat ini:

   Catatan

   Contoh ini menggunakan versi 384.111. Ganti dengan versi aktual Anda.

   1. Login ke node GPU dan jalankan perintah nvidia-smi untuk memeriksa versi driver.

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111

   2. Unduh installer yang sesuai dari NVIDIA untuk melakukan uninstall.

      cd /tmp/
      sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run

      Catatan

      Anda harus menggunakan paket instalasi untuk meng-uninstall driver NVIDIA.

   3. Uninstal driver NVIDIA saat ini.

      sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run
      sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q

5. Perbarui kernel.

   Anda dapat memperbarui kernel sesuai kebutuhan.

6. Restart GPU node.

   sudo reboot

7. Instal header kernel: Login kembali ke node GPU dan instal kernel-devel yang sesuai.

   sudo yum install -y kernel-devel-$(uname -r)

8. Instal driver NVIDIA baru: Kunjungi situs web NVIDIA untuk mengunduh dan menginstal driver NVIDIA yang diperlukan. Contoh ini menggunakan versi 410.79.

   # Change directory to /tmp
   cd /tmp/
   
   # Download the NVIDIA driver installer
   sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run
   
   # Make the installer executable
   sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run
   
   # Run the installer in silent mode
   sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q
   
   # Warm up the GPU
   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

9. Konfigurasikan mode persistensi: Pastikan pengaturan warm-up GPU berikut ada di /etc/rc.d/rc.local. Tambahkan secara manual jika perlu.

   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

10. Restart layanan:

    sudo service kubelet stop
    sudo service docker restart
    sudo service kubelet start

11. Uncordon node GPU:

    kubectl uncordon cn-beijing.i-2ze19qyi8votgjz*****
    
    node/cn-beijing.i-2ze19qyi8votgjz***** already uncordoned

12. Verifikasi: Jalankan nvidia-smi di dalam pod nvidia-device-plugin untuk mengonfirmasi versinya.

    kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz***** nvidia-smi
    Thu Jan 17 00:33:27 2019
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI 410.79       Driver Version: 410.79       CUDA Version: N/A      |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |===============================+======================+======================|
    |   0  Tesla P100-PCIE...  On   | 00000000:00:09.0 Off |                    0 |
    | N/A   27C    P0    28W / 250W |      0MiB / 16280MiB |      0%      Default |
    +-------------------------------+----------------------+----------------------+
    
    +-----------------------------------------------------------------------------+
    | Processes:                                                       GPU Memory |
    |  GPU       PID   Type   Process name                             Usage      |
    |=============================================================================|
    |  No running processes found                                                 |
    +-----------------------------------------------------------------------------+

    Catatan

    Jika Anda menjalankan perintah docker ps dan menemukan bahwa tidak ada kontainer yang dimulai pada node GPU, lihat Fix container startup failures on GPU nodes.

Perbaiki kegagalan startup kontainer pada node GPU

sudo service kubelet stop
# Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
# Redirecting to /bin/systemctl stop docker.service
sudo service docker start
# Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
# Redirecting to /bin/systemctl start kubelet.service

sudo docker ps
# Output: CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

sudo docker info | grep -i cgroup

Cgroup Driver: cgroupfs

Solusi

1. Perbarui konfigurasi Docker: Anda harus menyelaraskan Cgroup Driver dengan systemd dan memastikan runtime kontainer NVIDIA diatur sebagai default.

   1. Cadangkan konfigurasi Anda yang ada (file /etc/docker/daemon.json).

   2. Terapkan konfigurasi yang diperbaiki: Jalankan perintah berikut untuk menimpa /etc/docker/daemon.json dengan pengaturan yang diperlukan.

      sudo cat >/etc/docker/daemon.json <<-EOF
      {
          "default-runtime": "nvidia",
          "runtimes": {
              "nvidia": {
                  "path": "/usr/bin/nvidia-container-runtime",
                  "runtimeArgs": []
              }
          },
          "exec-opts": ["native.cgroupdriver=systemd"],
          "log-driver": "json-file",
          "log-opts": {
              "max-size": "100m",
              "max-file": "10"
          },
          "oom-score-adjust": -1000,
          "storage-driver": "overlay2",
          "storage-opts":["overlay2.override_kernel_check=true"],
          "live-restore": true
      }
      EOF

2. Restart layanan agar perubahan berlaku.

   sudo service kubelet stop
   # Redirecting to /bin/systemctl stop kubelet.service
   sudo service docker restart
   # Redirecting to /bin/systemctl restart docker.service
   sudo service kubelet start
   # Redirecting to /bin/systemctl start kubelet.service

3. Konfirmasi bahwa Cgroup Driver telah berhasil diubah ke systemd.

   sudo docker info | grep -i cgroup
   Cgroup Driver: systemd

Ketika node gagal, bagaimana cara memigrasikan pod secara batch untuk redeployment?

Anda dapat mengatur node yang gagal menjadi tidak dapat dijadwalkan dan melakukan drain untuk memindahkan pod aplikasi ke node yang sehat.

1. Login ke Konsol ACK.

2. Pada halaman Nodes, temukan node yang ingin Anda kelola. Di kolom Actions, pilih More > Drain. Operasi ini mengatur node lama menjadi tidak dapat dijadwalkan dan secara bertahap memigrasikan aplikasi dari node lama ke node baru.

3. Atasi masalah pada node yang gagal. Untuk detail troubleshooting, lihat Troubleshoot node issues.

Jika sebuah Kluster dengan node-node di beberapa zona mengalami kegagalan, bagaimana Kluster tersebut menentukan kebijakan penggantian node?

Umumnya, ketika node gagal, node controller mengganti pod dari node yang tidak sehat. Laju penggantian default --node-eviction-rate adalah 0,1 node per detik. Artinya, paling banyak satu pod diganti dari node setiap 10 detik.

Namun, ketika kluster ACK dengan node di beberapa zona mengalami kegagalan, node controller menentukan kebijakan penggantian berdasarkan kesehatan zona dan ukuran kluster.

Ada tiga jenis status kesehatan zona.

• FullDisruption: Zona tidak memiliki node sehat dan memiliki setidaknya satu node tidak sehat.

• PartialDisruption: Zona memiliki setidaknya dua node tidak sehat, dan proporsi node tidak sehat, yang dihitung sebagai (Jumlah node tidak sehat / (Jumlah node tidak sehat + Jumlah node sehat)), lebih besar dari 0,55.

• Normal: Bukan salah satu kondisi di atas.

Laju penggantian node controller dihitung sebagai berikut berdasarkan tiga status kesehatan zona:

• Jika semua zona berada dalam status FullDisruption, fitur penggantian dinonaktifkan untuk seluruh kluster.

• Jika beberapa zona berada dalam status FullDisruption, laju penggantian diatur ke nilai normal (0,1), terlepas dari ukuran kluster.

• Jika zona berada dalam status PartialDisruption, laju penggantian dipengaruhi oleh ukuran kluster.

  • Kluster besar (>50 node): Laju penggantian turun menjadi 0,01/detik.

  • Kluster kecil (≤50 node): Laju penggantian untuk zona adalah 0, artinya tidak ada penggantian yang terjadi.

• Jika zona berada dalam status Normal, laju penggantian diatur ke nilai normal (0,1), terlepas dari ukuran kluster.

Untuk informasi lebih lanjut, lihat Rate limits on eviction.

Dapatkah saya menyesuaikan jalur direktori kubelet?

Tidak. Jalur kubelet tetap di /var/lib/kubelet dan tidak dapat dikustomisasi di ACK.

Dapatkah saya memasang disk data ke direktori kustom di kelompok node ACK?

Fitur ini saat ini dalam rilis canary. Untuk mengajukan permohonan fitur ini, kirim tiket.

Setelah diaktifkan, Anda dapat memformat dan memasang disk ke jalur tertentu, dengan batasan berikut:

• Jangan memasang ke direktori OS yang dicadangkan berikut:

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• Jangan memasang ke direktori berikut yang digunakan oleh sistem dan runtime kontainer, atau subdirektorinya:

  • /usr

  • /bin

  • /sbin

  • /lib

  • /lib64

  • /ostree

  • /sysroot

  • /proc

  • /sys

  • /dev

  • /var/lib/kubelet

  • /var/lib/docker

  • /var/lib/containerd

  • /var/lib/container

• Direktori pemasangan untuk disk data berbeda harus unik.

• Direktori pemasangan harus berupa jalur mutlak yang dimulai dengan /.

• Direktori pemasangan tidak boleh mengandung karakter carriage return atau line feed (karakter escape gaya C \r dan \n) dan tidak boleh diakhiri dengan backslash (\).

Bagaimana cara memodifikasi jumlah maksimum deskriptor file?

Jumlah maksimum deskriptor file adalah jumlah maksimum file yang dapat dibuka secara bersamaan. Sistem Alibaba Cloud Linux dan CentOS memiliki dua tingkat batasan:

• Tingkat sistem: Jumlah maksimum file yang dapat dibuka secara bersamaan oleh proses semua pengguna.

• Tingkat pengguna: Jumlah maksimum file yang dapat dibuka oleh proses pengguna tunggal.

Dalam lingkungan kontainer, ada batasan lain: jumlah maksimum deskriptor file untuk proses tunggal di dalam kontainer.

Bagaimana cara meningkatkan runtime kontainer untuk node pekerja yang tidak termasuk dalam kelompok node?

Pada kluster lama yang dibuat sebelum pengenalan fitur kelompok node, mungkin terdapat node pekerja bebas. Untuk meningkatkan runtime kontainer node tersebut, Anda harus terlebih dahulu memigrasikannya ke kelompok node.

Prosedur:

1. Buat kelompok node: Jika tidak ada kelompok node yang sesuai, buat satu dengan konfigurasi yang sama dengan node bebas.

2. Hapus node: Selama proses penghapusan node, sistem mengatur node menjadi tidak dapat dijadwalkan dan melakukan drain. Jika drain gagal, sistem secara otomatis cordons node (mengatur menjadi tidak dapat dijadwalkan) dan melakukan operasi drain untuk mengganti pod. Jika drain berhasil, node dihapus dari kluster.

3. Tambahkan node yang ada: Tambahkan node target ke kelompok node yang ada. Setelah node bergabung kembali ke kluster, runtime kontainernya akan secara otomatis diperbarui agar sesuai dengan runtime yang ditentukan dalam konfigurasi kelompok node.

   Catatan

   Meskipun fitur kelompok node sendiri gratis, Anda akan ditagih untuk instans ECS yang mendasari dan sumber daya cloud lainnya. Untuk detailnya, lihat Cloud resource fees.

Mengapa konsol menampilkan sumber kelompok node sebagai Other Nodes?

ACK memungkinkan Anda menambahkan sumber daya komputasi melalui konsol, OpenAPI, atau CLI (lihat Add an existing node). Jika Anda menambahkan node melalui metode kustom yang tidak dikenali oleh manajemen siklus hidup standar ACK, konsol mengklasifikasikannya ke dalam kelompok Other Nodes.

ACK tidak dapat mengelola node ini melalui kelompok node, artinya fitur seperti O&M otomatis, manajemen siklus hidup, dan dukungan teknis terjamin tidak tersedia.

Jika Anda ingin terus menggunakan node ini, Anda harus memastikan kompatibilitasnya dengan add-on kluster dan menanggung risiko potensial. Risiko ini meliputi tetapi tidak terbatas pada:

• Ketidakcocokan versi: Selama peningkatan lapisan kontrol atau komponen sistem, OS dan komponen resident pada node ini mungkin menjadi tidak kompatibel dengan versi baru, berisiko mengganggu layanan.

• Konflik penjadwalan: Kluster mungkin gagal melaporkan zona ketersediaan atau kapasitas sisa sumber daya untuk node ini secara akurat. Hal ini dapat menyebabkan penjadwalan workload yang tidak tepat dan penurunan performa.

• Ketidaksesuaian bidang data: Kompatibilitas antara komponen/OS di sisi node dan lapisan kontrol kluster belum divalidasi, menimbulkan risiko stabilitas.

• Kegagalan O&M: Operasi pemeliharaan yang dilakukan melalui konsol ACK atau OpenAPI mungkin gagal atau menghasilkan hasil yang tidak terduga karena saluran manajemen dasar untuk node ini tidak diverifikasi.

Bagaimana cara mengonfigurasi ACL jaringan untuk vSwitch yang digunakan oleh node kluster？

Jika daftar kontrol akses (ACL) dikaitkan dengan vSwitch kelompok node, Anda harus secara eksplisit mengizinkan blok CIDR tertentu. Jika tidak, node baru akan gagal bergabung ke kluster atau akan muncul dalam status Failed atau Offline.

Prosedur untuk mengizinkan traffic dan menambahkan kembali node:

1. Konfigurasikan aturan ACL jaringan: Pastikan aturan inbound dan outbound mengizinkan traffic untuk blok CIDR berikut:

   • 100.104.0.0/16: CIDR manajemen lapisan kontrol ACK.

   • 100.64.0.0/10: CIDR layanan internal Alibaba Cloud.

   • 100.100.100.200/32: Alamat layanan metadata ECS.

   • CIDR VPC/vSwitch: Blok CIDR primer dan sekunder VPC, atau CIDR spesifik vSwitch node.

2. Hapus node yang bermasalah: Hapus node apa pun yang berada dalam status Failed atau Offline sebelum aturan ACL diterapkan.

3. Buat kelompok node atau perluas kelompok node yang ada: Jika status node berubah menjadi Ready, aturan ACL jaringan telah dikonfigurasi dengan benar.