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 dalam kluster yang berstatus NotReady. Jika ada node NotReady, 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 dalam kluster yang dapat memenuhi permintaan sumber daya CPU atau memori pod.

Node tidak dapat dijadwalkan ketika total alokasi requests mencapai kapasitas maksimum, meskipun penggunaan aktual rendah.

Pada 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. Turunkan konfigurasi requests workload. Lihat Tetapkan 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 mengurangi replika selama jam sepi.

• Bersihkan workload yang tidak diperlukan: Nonaktifkan atau kurangi jumlah pod yang tidak esensial.

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

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

Node yang ada tidak sesuai dengan kebijakan afinitas node pod (nodeAffinity/nodeSelector). Lihat Menetapkan Pod ke Node.

1. Lihat semua label pada node.

   Konsol

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

   2. Pada 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. Pada 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. Pada 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 mencakup afinitas keras (requiredDuringSchedulingIgnoredDuringExecution), yang harus dipenuhi, dan afinitas lunak (preferredDuringSchedulingIgnoredDuringExecution), yang menyatakan 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 bernilai 'ssd' atau 'nvme'.

   NodeSelector

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

   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 menjalankan pod dengan label yang cocok, sehingga penjadwalan gagal.

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

1. Lihat label pod pada node.

   Konsol

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

   2. Pada 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, misalnya 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, pada halaman Create Deployment 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 bersifat preferensi. Contoh berikut menunjukkan konfigurasi untuk pod affinity 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 pada 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. Hal ini biasanya terjadi karena disk cloud tidak dapat dipasang lintas zona berbeda.

• Untuk PV yang disediakan secara statis, konfigurasikan afinitas node pod agar dijadwalkan ke node dalam 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 dalam zona yang sama dengan node pod.

InvalidInstanceType.NotSupportDiskCategory

Instans ECS tidak mendukung tipe disk cloud yang ditentukan.

Lihat Jenis 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, hapus taint tersebut atau konfigurasikan toleransi untuk pod. Lihat Taints and Tolerations dan Kelola label dan taint node.

• Jika taint ditambahkan oleh sistem, selesaikan masalah dasar di bawah ini dan tunggu penjadwalan 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 pengontrol node. 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 ruang penyimpanan sementara yang tidak mencukupi.

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

2. Periksa total kapasitas penyimpanan sementara pada setiap node dengan kubectl describe node | grep -A10 Capacity. Jika 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. 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 dalam field spec.imagePullSecrets file YAML workload ada.

Saat menggunakan ACR, gunakan credential helper untuk menarik gambar tanpa kata sandi. Lihat Tarik 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 dalam 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. Masuk ke node tersebut (untuk informasi lebih lanjut, lihat Pilih metode koneksi jarak jauh ECS) dan jalankan perintah curl -kv https://xxxxxx/xxxxx/ untuk memeriksa apakah alamat tersebut 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.

Masuk ke node tersebut (lihat Pilih metode koneksi jarak jauh ECS) dan jalankan df -h untuk memeriksa ruang disk. Jika disk penuh, ubah ukurannya. Lihat Langkah 1: Ubah 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 Buat 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 merekomendasikan metode ini hanya untuk lingkungan pengujian, karena dapat memengaruhi pod lain pada node tersebut.

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

Operasi dibatalkan, kemungkinan karena file gambar terlalu besar. Kubernetes memiliki batas waktu default untuk menarik gambar. Jika penarikan tidak menunjukkan kemajuan dalam periode tertentu, Kubernetes menganggap operasi gagal atau tidak responsif dan membatalkan tugas.

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

2. Masuk ke node tempat pod berjalan (untuk informasi lebih lanjut, lihat Pilih 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. Masuk ke node tempat pod berjalan (untuk informasi lebih lanjut, lihat Pilih metode koneksi jarak jauh ECS) dan jalankan perintah curl https://xxxxxx/xxxxx/ untuk memeriksa apakah alamat tersebut 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 habis waktu karena masalah jaringan saat menarik gambar dari repositori luar negeri.

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

• Berlangganan gambar sumber luar negeri menggunakan Container Registry. Untuk petunjuknya, lihat Sinkronkan gambar menggunakan langganan artefak.

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

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 Sesuaikan konfigurasi kubelet kelompok node.

Pesan error

Deskripsi

Solusi

Terkunci dalam status Init:N/M

Pod memiliki M init container; N selesai, tetapi M-N sisanya gagal dimulai.

1. Periksa event pod dan masalah init container dengan kubectl describe pod -n <ns> <pod name>.

2. Periksa log init container yang belum dimulai dengan kubectl logs -n <ns> <pod name> -c <container name>.

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

Lihat Debug Init Containers.

Terkunci dalam status Init:Error

Salah satu init container dalam pod gagal dimulai.

Terkunci dalam status Init:CrashLoopBackOff

Salah satu init container dalam 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 versi yang lebih baru. Lihat Flannel.

Pada 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 versi yang lebih baru (disarankan versi terbaru). Lihat Tingkatkan 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 pada 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 tetap gagal dan error ini berlanjut, driver kemungkinan gagal memuat ENI karena memori orde tinggi tidak mencukupi. Restart instans ECS untuk mengatasi hal ini.

• 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 pada node untuk memeriksa proses alokasi ENI.

2. Lihat informasi ENI untuk pod Terway dengan kubectl logs -n kube-system  <terwayPodName > -c terway | grep <podName>. Dapatkan Request ID dan pesan error OpenAPI.

3. Gunakan Request ID dan pesan error untuk menyelidiki kegagalan tersebut.

Pesan error

Deskripsi

Solusi

Log berisi exit(0).

1. Masuk ke node tempat workload tidak normal ditempatkan.

2. Gunakan docker ps -a | grep $podName untuk memeriksa. Jika kontainer tidak memiliki proses persisten, kontainer tersebut keluar dengan kode status 0.

Event pod menunjukkan Liveness probe failed: ....

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

• Konfigurasi liveness probe: Pada 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 liveness probe dimulai hanya setelah aplikasi sepenuhnya diluncurkan.

  Anda dapat sementara menonaktifkan Liveness. Kemudian, akses terminal pod atau node hostnya 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 (startup probe) gagal, menyebabkan aplikasi restart.

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

  Anda dapat sementara menonaktifkan Startup. Kemudian, akses terminal pod atau node hostnya 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.

• Bersihkan gambar yang tidak diperlukan untuk membebaskan ruang disk, dan konfigurasikan imageGCHighThresholdPercent untuk mengatur ambang batas pengumpulan sampah gambar pada 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 antar 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 tidak diperlukan, ubah menjadi hostNetwork: false.

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

3. Verifikasi bahwa tidak ada pod lain pada 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 (nilainya secara otomatis di-encode Base64). Lihat Kelola Secret.

• 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 tersebut.

Pesan error

Deskripsi

Solusi

Event pod menunjukkan Readiness probe failed: ....

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

• Konfigurasi readiness probe: Pada halaman Edit Workloads target, verifikasi bahwa path pemeriksaan kesehatan (misalnya, /healthz) dan port sesuai dengan aplikasi. Jika aplikasi memulai dengan lambat, tingkatkan Unhealthy Threshold untuk menghindari kegagalan prematur.

  Nonaktifkan sementara Readiness, lalu gunakan curl dari terminal pod atau host untuk memverifikasi titik akhir pemeriksaan kesehatan.

• 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 (startup probe) yang gagal menyebabkan kontainer restart. Error ini seharusnya tidak menghasilkan status Running/NotReady yang persisten, melainkan status 'CrashLoopBackOff'.

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

Tingkat OOM

Deskripsi

Solusi yang direkomendasikan

Tingkat OS

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

• Tingkatkan memori node atau distribusikan workload ke lebih banyak node. Lihat Tingkatkan skala sumber daya node dan Jadwalkan aplikasi ke node tertentu.

• Identifikasi Pod bermemori tinggi pada node dan atur batas memori yang sesuai.

Tingkat cgroup

Periksa log kernel di /var/log/messages pada 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 pada tingkat cgroup.

• Tingkatkan batas memori Pod. Pertahankan penggunaan aktual di bawah 80% dari batas. Lihat Kelola Pod dan Tingkatkan skala sumber daya node.

• Aktifkan profil sumber daya untuk rekomendasi konfigurasi request dan limit 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.

Periksa konfigurasi finalizer pod dengan kubectl get pod -n <ns> <pod name> -o yaml dan selidiki 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.

Periksa konfigurasi hook preStop pod dengan kubectl get pod -n <ns> <pod name> -o yaml dan selidiki 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 responsif.

Saat Anda meminta 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. Hapus pod secara paksa dengan kubectl delete pod <pod-name> --grace-period=0 --force.

2. Periksa log containerd atau Docker pada node pod untuk investigasi lebih lanjut.

Kemungkinan penyebab

Deskripsi

Solusi yang direkomendasikan

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

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

• Periksa taint node dengan kubectl describe node <node name> | grep Taints. Output mungkin mencakup:

  • 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 dalam file YAML pod menunjukkan Evicted.

• Tekanan memori:

  • Sesuaikan konfigurasi sumber daya pod sesuai kebutuhan bisnis Anda. Lihat Kelola pod.

  • Tingkatkan node. Lihat Tingkatkan skala sumber daya node.

• Tekanan disk:

  • Bersihkan log aplikasi pada pod di node secara berkala untuk membebaskan ruang disk.

  • Perluas disk node. Lihat Langkah 1: Ubah ukuran disk cloud.

• Tekanan PID: Sesuaikan konfigurasi sumber daya pod. Lihat Batas dan Reservasi ID Proses.

Eviksi tidak terduga terjadi.

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

Periksa adanya taint NoExecute dengan kubectl describe node <node name> | grep Taints. Jika ada, hapus taint tersebut.

Eviksi tidak berjalan sesuai harapan.

• --pod-eviction-timeout: Pod pada node yang gagal dievksi setelah periode waktu habis ini. Defaultnya adalah 5 menit.

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

• --secondary-node-eviction-rate: Laju eviksi node sekunder. Jika terlalu banyak node dalam kluster gagal, laju eviksi dikurangi menjadi nilai ini. Defaultnya adalah 0,01.

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

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

Dalam kluster kecil (50 node atau kurang), jika lebih dari 55% node gagal, eviksi pod berhenti. Lihat Batas laju pada eviksi.

Dalam kluster besar (lebih dari 50 node), jika fraksi node tidak sehat melebihi --unhealthy-zone-threshold (default 0,55), laju eviksi turun menjadi --secondary-node-eviction-rate (default 0,01 pod per detik). Lihat Batas laju pada eviksi.

Pod sering dijadwalkan ulang ke node asalnya setelah dievksi.

Kubelet mengevksi 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 muat.

Sesuaikan permintaan sumber daya pod agar sesuai dengan sumber daya yang dapat dialokasikan node. Lihat Tetapkan sumber daya CPU dan memori untuk kontainer. Aktifkan profil sumber daya untuk mendapatkan nilai request dan limit yang direkomendasikan.