Container Service for Kubernetes:Pemecahan Masalah Pod

Pesan error

Deskripsi

Solusi

no nodes available to schedule pods.

Kluster tidak memiliki node yang tersedia untuk penjadwalan pod.

1. Periksa apakah ada node di kluster yang berstatus NotReady. Jika ada node NotReady, periksa dan perbaiki node tersebut.

2. Periksa apakah pod mendefinisikan nodeSelector, nodeAffinity, atau toleransi taint. Jika tidak ada kendala penjadwalan semacam itu, pertimbangkan untuk menambahkan lebih banyak node ke kelompok node.

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

Tidak ada node yang tersedia di kluster yang dapat memenuhi permintaan sumber daya CPU atau memori pod.

Node dianggap tidak dapat dijadwalkan jika jumlah alokasi sumber daya requests-nya telah mencapai kapasitasnya, meskipun penggunaan CPU atau memori aktualnya rendah.

Di halaman detail kluster target, buka Nodes > Nodes dan periksa tingkat alokasi requests CPU atau memori untuk node target. Anda dapat mengarahkan kursor ke tingkat alokasi untuk melihat nilai alokasi sumber daya spesifik.

Untuk melihat penggunaan sumber daya node secara rinci, lihat Gunakan kubectl untuk melihat penggunaan sumber daya node.

• Optimalkan konfigurasi sumber daya:

  • Jika penggunaan sumber daya node secara konsisten lebih rendah daripada requests-nya, berarti sumber daya terbuang sia-sia. Anda dapat menurunkan konfigurasi requests untuk workload. Untuk informasi lebih lanjut, lihat Atur batas sumber daya CPU dan memori untuk kontainer.

    Anda dapat mengaktifkan profil sumber daya untuk mendapatkan rekomendasi konfigurasi requests.

  • Aktifkan Horizontal Pod Autoscaler (HPA) untuk kontainer bisnis Anda agar mengurangi jumlah replika selama jam sepi, sehingga menurunkan konsumsi sumber daya secara keseluruhan.

• Bersihkan workload yang tidak diperlukan: Nonaktifkan atau kurangi skala pod yang tidak penting.

• Perluas kelompok node: Jika penggunaan sumber daya pada node target secara konsisten tinggi, berarti node sudah jenuh. Anda dapat memperluas kelompok node.

x node(s) didn't match pod's node affinity/selector.

Node yang ada di kluster tidak sesuai dengan kebijakan afinitas node (nodeAffinity/nodeSelector) yang dideklarasikan untuk Pod. Untuk informasi lebih lanjut, lihat Menetapkan Pod ke Node.

1. Lihat semua label pada node.

   Konsol

   1. Di halaman detail kluster target, buka Nodes > Nodes.

   2. Di halaman Nodes, temukan node target, lalu di kolom Actions, klik More > Manage Labels and Taints untuk melihat label-nya.

   Kubectl

   Ganti <YOUR_NODE_NAME> dengan nama node aktual Anda.

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. Periksa dan sesuaikan aturan afinitas node untuk workload (deployment).

   Konsol

   Saat membuat workload baru:

   1. Di halaman Advanced untuk membuat Create Deployment, temukan Node Affinity di bagian Scheduling, lalu klik Add.

   2. Konfigurasikan Required (afinitas keras) atau Optional (afinitas lunak) sesuai kebutuhan bisnis Anda. Beberapa Selector memiliki hubungan logika AND, sedangkan beberapa Rule memiliki hubungan logika OR.

   Untuk workload yang sudah ada:

   1. Di halaman Nodes > Nodes, klik > Node Affinity di kolom Actions Deployment target.

   2. Metode konfigurasinya sama seperti yang dijelaskan di atas.

   Contoh YAML

   NodeAffinity

   Kebijakan afinitas dibagi menjadi afinitas keras (requiredDuringSchedulingIgnoredDuringExecution) dan afinitas lunak (preferredDuringSchedulingIgnoredDuringExecution). Afinitas keras menentukan aturan yang harus dipenuhi, sedangkan afinitas lunak menentukan preferensi. Contoh berikut menggunakan afinitas keras.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-affinity-deploy
     labels:
       app: demo-node-affinity
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-node-affinity
     template:
       metadata:
         labels:
           app: demo-node-affinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           nodeAffinity:
             # Afinitas keras: Aturan ini harus dipenuhi.
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: disktype
                   operator: In
                   values:
                   - ssd
                   - nvme  # Logika: Label 'disktype' node harus 'ssd' atau 'nvme'.

   NodeSelector

   Ini menyediakan pencocokan eksak sederhana. Pod hanya dijadwalkan jika label node memenuhi kondisi.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-node-selector-deploy
     labels:
       app: demo-node-selector
   spec:
     replicas: 2  
     selector:
       matchLabels:
         app: demo-node-selector  
     template:
       metadata:
         labels:
           app: demo-node-selector
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         # Pod hanya dijadwalkan jika node memiliki label disktype=ssd.
         nodeSelector:
           disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• Ketidakcocokan aturan afinitas. Pod memiliki aturan pod affinity (misalnya, memerlukan label tertentu), tetapi tidak ada node yang meng-host pod dengan label yang cocok, sehingga mencegah penjadwalan.

• Konflik anti-afinitas. Pod memiliki aturan pod anti-affinity (misalnya, tidak boleh berada bersama aplikasi lain), tetapi semua node yang tersedia sudah meng-host pod yang bertentangan, sehingga mencegah penjadwalan.

1. Lihat label pod pada node.

   Konsol

   1. Di halaman detail kluster target, buka Nodes > Nodes.

   2. Di halaman Nodes, klik nama node target untuk membuka halaman detailnya. Gulir ke bawah ke bagian Pods untuk melihat nilai label berbagai pod di kolom Label.

   Kubectl

   • Lihat pod dan label-nya pada node tertentu: Ganti <YOUR_NAMESPACE> dengan nama namespace Anda dan <YOUR_NODE_NAME> dengan nama node aktual Anda.

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • Kueri pod berdasarkan label: Ganti <LABEL> dengan pasangan kunci-nilai label aktual, seperti app=nginx.

     kubectl get pods -A -l <LABEL> -o wide

2. Periksa dan sesuaikan aturan afinitas pod untuk workload (deployment).

   Konsol

   1. Saat membuat workload baru, di halaman Create Deployment, buka halaman Advanced, temukan Pod Affinity/Pod Anti-affinity di bagian Scheduling, lalu klik Add.

   2. Konfigurasikan Required (afinitas keras) atau Optional (afinitas lunak) sesuai kebutuhan bisnis Anda. Beberapa Selector memiliki hubungan logika AND, sedangkan beberapa Add Rule memiliki hubungan logika OR.

   Contoh YAML

   Kebijakan afinitas diklasifikasikan menjadi afinitas keras (requiredDuringSchedulingIgnoredDuringExecution) dan afinitas lunak (preferredDuringSchedulingIgnoredDuringExecution). Aturan afinitas keras harus dipenuhi, sedangkan aturan afinitas lunak merupakan preferensi. Contoh berikut menunjukkan konfigurasi untuk pod affinity yang wajib.

   Untuk mengonfigurasi pod anti-affinity, cukup ganti podAffinity dengan podAntiAffinity.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: app-demo-podaffinity-deploy
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: demo-podaffinity
     template:
       metadata:
         labels:
           app: demo-podaffinity
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         affinity:
           podAffinity:
             # Afinitas keras: Pod harus berada di node yang sama dengan pod yang memiliki label 'app: nginx'.
             requiredDuringSchedulingIgnoredDuringExecution:
             - labelSelector:
                 matchExpressions:
                 - key: app
                   operator: In
                   values:
                   - nginx
               # Cakupan domain topologi: isolasi tingkat host.
               topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

Penjadwalan gagal karena konflik afinitas node volume. Ini biasanya terjadi karena disk cloud tidak dapat dipasang lintas zona berbeda.

• Untuk PV yang disediakan secara statis, konfigurasikan afinitas node pod untuk memastikan pod dijadwalkan ke node di zona yang sama dengan PV.

• Untuk PV yang disediakan secara dinamis, atur volumeBindingMode StorageClass ke WaitForFirstConsumer. Ini memastikan PV dibuat hanya setelah pod dijadwalkan ke node, sehingga disk cloud dibuat di zona yang sama dengan node pod.

InvalidInstanceType.NotSupportDiskCategory

Instans ECS tidak mendukung tipe disk cloud yang ditentukan.

Lihat Famili instans untuk mengonfirmasi tipe disk cloud yang didukung oleh instans ECS Anda. Saat memasang, perbarui tipe disk cloud ke tipe yang didukung oleh instans ECS.

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

Pod tidak dapat dijadwalkan ke node karena tidak memiliki toleransi terhadap salah satu taint node tersebut.

• Jika taint ditambahkan secara manual, Anda dapat menghapus taint yang tidak diinginkan. Jika taint tidak dapat dihapus, Anda dapat mengonfigurasi toleransi yang sesuai untuk pod. Untuk informasi lebih lanjut, lihat Taints and Tolerations dan Mengelola label dan taint node.

• Jika taint ditambahkan secara otomatis oleh sistem, selesaikan masalah mendasarnya seperti dijelaskan di bawah ini dan tunggu pod dijadwalkan ulang.

  Lihat taint yang ditambahkan oleh sistem

  • node.kubernetes.io/not-ready: Node berada dalam status NotReady.

  • node.kubernetes.io/unreachable: Node tidak dapat dijangkau dari node controller. Ini setara dengan status Ready node menjadi Unknown.

  • node.kubernetes.io/memory-pressure: Node mengalami tekanan memori.

  • node.kubernetes.io/disk-pressure: Node mengalami tekanan disk.

  • node.kubernetes.io/pid-pressure: Node mengalami tekanan PID.

  • node.kubernetes.io/network-unavailable: Jaringan node tidak tersedia.

  • node.kubernetes.io/unschedulable: Node ditandai sebagai tidak dapat dijadwalkan.

0/x nodes are available: x Insufficient ephemeral-storage.

Node memiliki penyimpanan sementara yang tidak mencukupi.

1. Periksa permintaan penyimpanan sementara Pod, yaitu nilai spec.containers.resources.requests.ephemeral-storage di YAML Pod. Jika nilainya terlalu tinggi dan melebihi kapasitas aktual node, Pod akan gagal dijadwalkan.

2. Jalankan perintah kubectl describe node | grep -A10 Capacity untuk melihat total kapasitas penyimpanan sementara di setiap node. Jika kapasitas tidak mencukupi, perluas disk node atau tambahkan lebih banyak node.

0/x nodes are available: pod has unbound immediate persistent volume claims.

Pod gagal mengikat klaim volume persisten (PVC).

Periksa apakah PVC atau PV yang ditentukan oleh pod telah dibuat. Jalankan kubectl describe pvc <pvc-name> atau kubectl describe pv <pv-name> untuk melihat event PVC dan PV guna diagnosis lebih lanjut. Untuk informasi lebih lanjut, lihat FAQ Penyimpanan - CSI.

Pesan error

Deskripsi

Solusi yang disarankan

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

Akses ke repositori gambar ditolak karena imagePullSecret tidak ditentukan saat pod dibuat.

Verifikasi bahwa Secret yang ditentukan di field spec.imagePullSecrets file YAML workload ada.

Saat menggunakan Container Registry (ACR), Anda dapat menggunakan credential helper untuk menarik gambar tanpa kata sandi. Untuk informasi lebih lanjut, lihat Menarik gambar dari akun yang sama.

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

Alamat repositori gambar tidak dapat diselesaikan saat menarik gambar melalui HTTPS.

1. Verifikasi bahwa alamat repositori gambar di spec.containers.image file YAML pod benar. Jika salah, perbarui.

2. Jika alamatnya benar, verifikasi konektivitas jaringan dari node tempat pod berjalan ke repositori gambar. Login ke node (untuk informasi lebih lanjut, lihat Memilih metode koneksi jarak jauh ECS) dan jalankan perintah curl -kv https://xxxxxx/xxxxx/ untuk memeriksa apakah alamat dapat diakses. Jika terjadi error, selidiki kemungkinan masalah jaringan, seperti konfigurasi jaringan salah, aturan firewall, atau masalah resolusi DNS.

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

Node memiliki ruang disk yang tidak mencukupi.

Login ke node tempat pod berjalan (untuk informasi lebih lanjut, lihat Memilih metode koneksi jarak jauh ECS) dan jalankan df -h untuk memeriksa ruang disk. Jika disk penuh, ubah ukuran disk cloud. Untuk informasi lebih lanjut, lihat Langkah 1: Mengubah ukuran disk cloud.

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

Repositori gambar pihak ketiga menggunakan sertifikat yang ditandatangani oleh Certificate Authority (CA) yang tidak dikenal atau tidak aman.

1. Repositori pihak ketiga sebaiknya menggunakan sertifikat yang dikeluarkan oleh CA tepercaya.

2. Jika Anda menggunakan repositori gambar pribadi, lihat Membuat aplikasi dari repositori gambar pribadi.

3. Jika Anda tidak dapat mengubah sertifikat, Anda dapat mengonfigurasi node untuk mengizinkan penarikan dan pendorongan gambar dari repositori yang menggunakan sertifikat tidak aman. Kami menyarankan menggunakan metode ini hanya di lingkungan pengujian, karena dapat memengaruhi pod lain di node tersebut.

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

Operasi dibatalkan, kemungkinan karena file gambar terlalu besar. Kubernetes memiliki timeout default untuk menarik gambar. Jika penarikan tidak menunjukkan progres selama periode tertentu, Kubernetes menganggap operasi gagal atau tidak merespons dan membatalkan tugas.

1. Verifikasi bahwa imagePullPolicy diatur ke IfNotPresent di file YAML pod.

2. Login ke node tempat pod berjalan (untuk informasi lebih lanjut, lihat Memilih metode koneksi jarak jauh ECS) dan jalankan docker pull atau crictl pull untuk memeriksa apakah gambar dapat ditarik.

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Tidak dapat terhubung ke repositori gambar karena masalah jaringan.

1. Login ke node tempat pod berjalan (untuk informasi lebih lanjut, lihat Memilih metode koneksi jarak jauh ECS) dan jalankan perintah curl https://xxxxxx/xxxxx/ untuk memeriksa apakah alamat dapat diakses. Jika terjadi error, selidiki kemungkinan masalah jaringan, seperti konfigurasi jaringan salah, aturan firewall, atau masalah resolusi DNS.

2. Verifikasi kebijakan jaringan publik node, termasuk konfigurasi untuk entri SNAT dan Alamat IP Elastis (EIP) yang terikat.

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

Koneksi timeout karena masalah jaringan saat menarik gambar dari repositori luar negeri.

Menarik gambar dari repositori luar negeri, seperti Docker Hub, mungkin gagal di kluster ACK karena jaringan penyedia layanan tidak stabil. Untuk mengatasi hal ini, pertimbangkan solusi berikut:

• Berlangganan gambar sumber luar negeri menggunakan Container Registry. Untuk petunjuknya, lihat Menyinkronkan gambar dari sumber di luar Tiongkok menggunakan langganan artefak.

• Buat instans Global Accelerator (GA) untuk menarik gambar langsung menggunakan jaringan akselerasi globalnya. Untuk detailnya, lihat Menggunakan GA untuk mempercepat penarikan gambar kontainer lintas wilayah di ACK.

Too Many Requests.

Docker Hub memberlakukan pembatasan laju pada permintaan penarikan gambar.

Unggah gambar ke Container Registry (ACR) dan tarik dari repositori gambar ACR.

Status Pulling image terus-menerus ditampilkan

Mekanisme pembatasan laju penarikan gambar kubelet mungkin telah dipicu.

Sesuaikan registryPullQPS (QPS maksimum untuk repositori gambar) dan registryBurst (jumlah maksimum penarikan gambar burst) menggunakan fitur Menyesuaikan konfigurasi kubelet untuk kelompok node.

Pesan error

Deskripsi

Solusi

Terkunci dalam status Init:N/M

Pod berisi M init container. N di antaranya telah selesai, tetapi M-N init container yang tersisa gagal dimulai.

1. Jalankan perintah kubectl describe pod -n <ns> <pod name> untuk melihat event pod dan memeriksa masalah pada init container yang belum dimulai.

2. Jalankan perintah kubectl logs -n <ns> <pod name> -c <container name> untuk melihat log init container yang belum dimulai dan gunakan untuk memecahkan masalah.

3. Tinjau konfigurasi pod, seperti pengaturan pemeriksaan kesehatan, untuk memastikan init container dikonfigurasi dengan benar.

Untuk informasi lebih lanjut tentang init container, lihat Debug init containers.

Terkunci dalam status Init:Error

Init container di pod gagal dimulai.

Terkunci dalam status Init:CrashLoopBackOff

Init container di pod gagal dimulai dan berada dalam loop restart.

Pesan error

Deskripsi

Solusi

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

Ini adalah perilaku yang diharapkan karena desain plugin jaringan Flannel.

Tingkatkan komponen Flannel ke v0.15.1.11-7e95fe23-aliyun atau yang lebih baru. Untuk informasi lebih lanjut, lihat Flannel.

Di kluster yang menjalankan versi Kubernetes sebelum 1.20, kebocoran alamat IP dapat terjadi jika pod restart berulang kali atau jika pod dari CronJob menyelesaikan tugasnya dan keluar dengan cepat.

Tingkatkan kluster ke Kubernetes 1.20 atau yang lebih baru. Kami menyarankan menggunakan versi kluster terbaru. Untuk informasi lebih lanjut, lihat Meningkatkan kluster secara manual.

Cacat pada containerd dan runC menyebabkan masalah ini.

Untuk perbaikan darurat, lihat Mengapa pod saya gagal dimulai dengan error "no IP addresses available in range"?

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

Plugin jaringan Terway memelihara basis data internal di node untuk melacak dan mengelola elastic network interfaces (ENIs). Error ini terjadi ketika status basis data tidak konsisten dengan konfigurasi perangkat jaringan aktual, menyebabkan alokasi ENI gagal.

1. Antarmuka jaringan dimuat secara asinkron. Antarmuka mungkin masih dimuat selama konfigurasi CNI, yang memicu percobaan ulang CNI otomatis. Proses ini tidak memengaruhi alokasi ENI akhir. Periksa status akhir pod untuk mengonfirmasi keberhasilan.

2. Jika pembuatan pod masih gagal setelah waktu lama dan error ini tetap ada, driver kemungkinan gagal memuat ENI karena memori orde tinggi tidak mencukupi. Restart instans ECS untuk mengatasi masalah ini. Untuk informasi lebih lanjut, lihat Restart instans.

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

Plugin jaringan Terway mungkin gagal meminta alamat IP dari vSwitch.

1. Lihat log kontainer Terway dalam pod komponen Terway di node untuk memeriksa proses alokasi ENI.

2. Jalankan perintah kubectl logs -n kube-system  <terwayPodName > -c terway | grep <podName> untuk melihat informasi ENI untuk pod Terway. Dapatkan ID Permintaan untuk permintaan alamat IP dan pesan error OpenAPI.

3. Gunakan ID Permintaan dan pesan error untuk menyelidiki kegagalan.

Pesan error

Deskripsi

Solusi

Log berisi exit(0).

1. Login ke node tempat workload tidak normal ditempatkan.

2. Jalankan perintah docker ps -a | grep $podName. Jika kontainer tidak memiliki proses persisten, ia akan keluar dengan kode status 0.

Event pod menunjukkan Liveness probe failed: ....

Pemeriksaan kelangsungan hidup (liveness probe) gagal, menyebabkan aplikasi restart.

• Konfigurasi pemeriksaan kelangsungan hidup: Di halaman Edit Workloads target, verifikasi bahwa path permintaan pemeriksaan kesehatan (misalnya, /healthz) dan port sesuai dengan yang disediakan oleh aplikasi. Tingkatkan Initial Delay (s) untuk memastikan pemeriksaan kelangsungan hidup dimulai hanya setelah aplikasi sepenuhnya diluncurkan.

  Anda dapat sementara menonaktifkan Liveness. Kemudian, akses terminal pod atau node host-nya dan gunakan perintah seperti curl untuk memverifikasi bahwa metode pemeriksaan kesehatan berfungsi dengan benar.

• Pecahkan masalah aplikasi: Selidiki masalah dengan memeriksa Events dan Log pod. Pilih Show the log of the last container exit.

Event pod menunjukkan Startup probe failed: ....

Pemeriksaan startup gagal, menyebabkan aplikasi restart.

• Konfigurasi pemeriksaan startup: Di halaman Edit Workloads target, verifikasi bahwa path permintaan pemeriksaan kesehatan (misalnya, /healthz) dan port sesuai dengan yang disediakan oleh aplikasi. Jika aplikasi membutuhkan waktu lama untuk memulai, tingkatkan Unhealthy Threshold untuk mencegah restart prematur.

  Anda dapat sementara menonaktifkan Startup. Kemudian, akses terminal pod atau node host-nya dan gunakan perintah seperti curl untuk memverifikasi bahwa metode pemeriksaan kesehatan berfungsi dengan benar.

• Pecahkan masalah aplikasi: Selidiki masalah dengan memeriksa Events dan Logs pod. Pilih Show the log of the last container exit.

Log pod berisi no space left on device.

Ruang disk cloud tidak mencukupi.

• Ubah ukuran disk cloud. Untuk informasi lebih lanjut, lihat Langkah 1: Mengubah ukuran disk cloud.

• Bersihkan gambar yang tidak diperlukan untuk mengosongkan ruang disk, dan konfigurasikan imageGCHighThresholdPercent untuk mengatur ambang batas pengumpulan sampah gambar di node.

Startup gagal tanpa informasi event.

Masalah ini terjadi ketika kontainer memerlukan lebih banyak sumber daya daripada batas yang dideklarasikan, menyebabkan kegagalan.

Periksa apakah konfigurasi sumber daya pod benar. Anda dapat mengaktifkan profil sumber daya untuk mendapatkan rekomendasi konfigurasi Request dan Limit untuk kontainer.

Log pod menunjukkan Address already in use.

Terjadi konflik port antara kontainer dalam pod yang sama.

1. Periksa apakah pod dikonfigurasi dengan hostNetwork: true. Pengaturan ini menyebabkan kontainer dalam pod berbagi namespace jaringan dan ruang port host. Jika ini tidak diperlukan, ubah menjadi hostNetwork: false.

2. Jika pod memerlukan hostNetwork: true, konfigurasikan anti-afinitas pod untuk memastikan pod dari set replika yang sama dijadwalkan ke node berbeda.

3. Verifikasi bahwa tidak ada pod lain di node yang sama yang menggunakan port tersebut.

Log pod menunjukkan container init caused "setenv: invalid argument": unknown.

Workload memasang Secret, tetapi nilai dalam Secret tidak di-encode Base64.

• Buat Secret di konsol, di mana nilai secara otomatis di-encode Base64. Untuk informasi lebih lanjut, lihat Mengelola Secrets.

• Buat Secret dari file YAML dan encode Base64 nilai secara manual dengan menjalankan perintah echo -n "xxxxx" | base64.

Masalah spesifik aplikasi.

Periksa log pod untuk memecahkan masalah.

Pesan error

Deskripsi

Solusi

Event pod menunjukkan Readiness probe failed: ....

Pemeriksaan kesiapan (readiness probe) gagal, mencegah pod target menerima trafik.

• Konfigurasi pemeriksaan kesiapan: Di halaman Edit Workloads target, verifikasi bahwa path permintaan pemeriksaan kesehatan (misalnya, /healthz) dan port sesuai dengan yang disediakan oleh aplikasi. Jika aplikasi memiliki waktu startup yang lama, tingkatkan Unhealthy Threshold untuk menghindari kegagalan prematur.

  Anda dapat sementara menonaktifkan Readiness, login ke terminal Pod atau host-nya, dan gunakan perintah seperti curl untuk memverifikasi bahwa metode pemeriksaan kesehatan merespons dengan benar.

• Pecahkan masalah aplikasi: Selidiki masalah dengan memeriksa Events dan Logs pod. Pilih Show the log of the last container exit.

Status pod sama seperti di atas. Event pod menunjukkan Startup probe failed: ....

Pemeriksaan startup yang gagal menyebabkan kontainer restart. Error ini seharusnya tidak menghasilkan status Running/NotReady yang persisten, melainkan status 'CrashLoopBackOff'.

Pecahkan masalah ini seperti yang dijelaskan di bagian "Pod gagal dimulai (CrashLoopBackOff)" untuk Startup.

Tingkat OOM

Deskripsi

Solusi yang direkomendasikan

Tingkat OS

Periksa log kernel di /var/log/messages di node pod. Jika log menunjukkan proses yang dihentikan tetapi tidak berisi log cgroup, event OOM terjadi di tingkat OS.

• Tingkatkan sumber daya memori node atau distribusikan workload ke lebih banyak node. Untuk informasi lebih lanjut, lihat Memperluas sumber daya node dan Menjadwalkan aplikasi ke node tertentu.

• Identifikasi Pod di node dengan konsumsi memori tinggi dan atur batas memori yang sesuai untuknya.

Tingkat cgroup

Periksa log kernel di /var/log/messages di node pod. Jika log berisi pesan error serupa Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx, event OOM terjadi di tingkat cgroup.

• Tingkatkan batas memori Pod berdasarkan kebutuhan bisnis Anda. Kami menyarankan agar penggunaan aktual tetap di bawah 80% dari batas yang dikonfigurasi. Untuk informasi lebih lanjut, lihat Mengelola Pod dan Memperluas sumber daya node.

• Aktifkan profil sumber daya untuk mendapatkan rekomendasi konfigurasi requests dan limits kontainer.

Kemungkinan penyebab

Deskripsi

Solusi yang direkomendasikan

Node berada dalam status NotReady.

Pod secara otomatis dihapus setelah node pulih dari status NotReady.

Pod dikonfigurasi dengan finalizer.

Jika pod dikonfigurasi dengan finalizer, Kubernetes melakukan operasi pembersihan yang ditentukan oleh finalizer sebelum menghapus pod. Jika operasi pembersihan gagal merespons, pod tetap dalam status Terminating.

Jalankan perintah kubectl get pod -n <ns> <pod name> -o yaml untuk melihat konfigurasi finalizer pod dan menyelidiki penyebabnya.

Hook preStop pod tidak valid atau macet.

Jika hook preStop dikonfigurasi untuk pod, Kubernetes mengeksekusi hook tersebut sebelum menghentikan kontainer. Pod tetap dalam status Terminating selama hook berjalan.

Jalankan perintah kubectl get pod -n <ns> <pod name> -o yaml untuk melihat konfigurasi hook preStop pod dan menyelidiki penyebabnya.

Periode shutdown yang mulus dikonfigurasi untuk pod.

Jika Pod dikonfigurasi dengan periode shutdown yang mulus (terminationGracePeriodSeconds), Pod memasuki status Terminating setelah menerima perintah penghentian, seperti kubectl delete pod <pod_name>. Kubernetes menganggap Pod berhasil dimatikan hanya setelah waktu yang ditentukan dalam terminationGracePeriodSeconds berlalu atau kontainer keluar.

Kubernetes secara otomatis menghapus pod setelah kontainer menyelesaikan shutdown yang mulus.

Kontainer tidak merespons.

Saat Anda meminta untuk menghentikan atau menghapus pod, Kubernetes mengirim sinyal SIGTERM ke kontainer dalam pod. Jika kontainer tidak menangani sinyal SIGTERM dengan benar selama penghentian, pod mungkin tetap dalam status Terminating.

1. Jalankan perintah kubectl delete pod <pod-name> --grace-period=0 --force untuk menghapus pod secara paksa dan melepaskan sumber dayanya.

2. Periksa log containerd atau Docker di node pod untuk menyelidiki lebih lanjut.

Kemungkinan penyebab

Deskripsi

Solusi yang direkomendasikan

Node mengalami tekanan sumber daya dari faktor seperti penggunaan memori atau disk.

Node mungkin mengalami tekanan memori, tekanan disk, atau tekanan PID.

• Jalankan perintah kubectl describe node <node name> | grep Taints. Output mungkin mencakup taint berikut:

  • Tekanan memori: Node memiliki taint node.kubernetes.io/memory-pressure.

  • Tekanan disk: Node memiliki taint node.kubernetes.io/disk-pressure.

  • Tekanan PID: Node memiliki taint node.kubernetes.io/pid-pressure.

• Status pod adalah salah satu dari berikut:

  • Evicted

  • ContainerStatusUnknown, dan field reason di file YAML pod menunjukkan Evicted.

• Tekanan memori:

  • Sesuaikan konfigurasi sumber daya pod berdasarkan kebutuhan bisnis Anda. Untuk informasi lebih lanjut, lihat Mengelola pod.

  • Tingkatkan node. Untuk informasi lebih lanjut, lihat Memperluas sumber daya node.

• Tekanan disk:

  • Bersihkan log aplikasi dari pod di node secara berkala untuk mengosongkan ruang disk.

  • Perluas disk node. Untuk informasi lebih lanjut, lihat Langkah 1: Mengubah ukuran disk cloud.

• Tekanan PID: Sesuaikan konfigurasi sumber daya pod berdasarkan kebutuhan bisnis Anda. Untuk informasi lebih lanjut, lihat Batas dan Reservasi ID Proses.

Eviksi tidak terduga terjadi.

Taint NoExecute yang ditambahkan secara manual pada node pod menyebabkan eviksi tidak terduga.

Jalankan perintah kubectl describe node <node name> | grep Taints untuk memeriksa apakah node memiliki taint NoExecute. Jika ya, hapus.

Eviksi tidak berjalan seperti yang diharapkan.

• --pod-eviction-timeout: Pod di node yang gagal dieviksi setelah periode timeout ini. Defaultnya adalah 5 menit.

• --node-eviction-rate: Jumlah pod yang dieviksi dari node per detik. Defaultnya adalah 0,1, artinya paling banyak satu pod dieviksi dari node setiap 10 detik.

• --secondary-node-eviction-rate: Tingkat eviksi node sekunder. Jika terlalu banyak node di kluster gagal, tingkat eviksi dikurangi ke nilai ini. Defaultnya adalah 0,01.

• --unhealthy-zone-threshold: Ambang batas zona ketersediaan tidak sehat. Defaultnya adalah 0,55. Ketika fraksi node yang gagal di zona ketersediaan melebihi ambang batas ini, zona dianggap tidak sehat.

• --large-cluster-size-threshold: Ambang batas ukuran kluster besar. Defaultnya adalah 50. Kluster dianggap besar ketika memiliki lebih dari 50 node.

Di kluster kecil (50 node atau kurang), jika lebih dari 55% node gagal, eviksi pod berhenti. Untuk informasi lebih lanjut, lihat Batas laju eviksi.

Di kluster besar (lebih dari 50 node), jika fraksi node tidak sehat melebihi --unhealthy-zone-threshold (default 0,55), tingkat eviksi berkurang ke nilai --secondary-node-eviction-rate (default 0,01 pod per detik). Untuk informasi lebih lanjut, lihat Batas laju eviksi.

Pod sering dijadwalkan ulang ke node asalnya setelah dieviksi.

Kubelet mengeviksi pod berdasarkan penggunaan sumber daya aktual, sedangkan penjadwal menempatkan pod berdasarkan permintaan sumber daya. Karena eviksi membebaskan sumber daya, penjadwal mungkin menjadwalkan ulang pod ke node yang sama jika permintaannya masih sesuai.

Pastikan permintaan sumber daya pod sesuai untuk sumber daya yang dapat dialokasikan node, dan sesuaikan jika perlu. Untuk informasi lebih lanjut, lihat Menetapkan sumber daya CPU dan memori untuk kontainer. Anda juga dapat mengaktifkan profil sumber daya untuk mendapatkan rekomendasi konfigurasi request dan limit untuk kontainer Anda.