Prosedur Operasi Standar Pemecahan Masalah Pod - Container Service for Kubernetes

Topik ini menjelaskan prosedur diagnostik untuk pod serta cara memecahkan masalah kesalahan pod. Topik ini juga memberikan jawaban atas beberapa pertanyaan umum terkait pod.

Catatan

Untuk mempelajari cara memecahkan masalah pod di konsol, lihat Memecahkan Masalah di Konsol. Di konsol, Anda dapat melihat status, informasi dasar, konfigurasi, peristiwa, dan log pod, menggunakan terminal untuk mengakses kontainer, serta mengaktifkan diagnostik pod.

Prosedur Diagnostik

Jika pod tidak berjalan secara normal, Anda dapat mengidentifikasi penyebabnya dengan memeriksa peristiwa, log, dan konfigurasi pod. Gambar berikut menunjukkan prosedurnya.

Fase 1: Masalah Penjadwalan

Pod gagal dijadwalkan

Jika pod tetap dalam keadaan Pending untuk waktu yang lama, itu berarti pod gagal dijadwalkan. Tabel berikut menjelaskan kemungkinan penyebabnya.

Pesan Kesalahan	Deskripsi	Solusi yang Disarankan
`tidak ada node yang tersedia untuk menjadwalkan pod.`	Kluster tidak memiliki node yang tersedia untuk penjadwalan pod.	Periksa apakah node dalam kluster berada dalam keadaan NotReady. Jika sebuah node berada dalam keadaan NotReady, perbaiki node tersebut. Periksa apakah pemilih node, aturan afinitas node, atau toleransi taint dikonfigurasikan untuk pod. Jika tidak ada aturan afinitas yang dikonfigurasikan untuk pod, tambahkan jumlah node dalam pool node.
`0/x nodes are available: x Insufficient cpu.` `0/x nodes are available: x Insufficient memory.`	Kluster tidak memiliki node yang dapat memenuhi permintaan CPU atau memori pod.	Di halaman Nodes, lihat penggunaan pod, CPU, dan memory serta periksa pemanfaatan sumber daya kluster. Catatan Ketika pemanfaatan CPU dan memori node dipertahankan pada tingkat rendah, menjadwalkan pod baru ke node tidak akan menghabiskan sumber daya node. Namun, penjadwal masih memeriksa apakah pod baru akan menyebabkan kekurangan sumber daya selama jam sibuk dan mencoba menghindari penjadwalan sumber daya yang tidak tepat. Ketika sumber daya CPU atau memori dalam kluster habis, gunakan metode berikut: Hapus pod yang tidak diperlukan. Untuk informasi lebih lanjut, lihat Kelola pod. Ubah konfigurasi sumber daya pod. Untuk informasi lebih lanjut, lihat Ubah batas atas dan bawah sumber daya CPU dan memori untuk pod. Aktifkan profil sumber daya untuk mendapatkan permintaan sumber daya dan batas yang disarankan untuk kontainer. Tambahkan node ke kluster berdasarkan aturan afinitas pod. Untuk informasi lebih lanjut, lihat Buat dan kelola pool node. Tingkatkan node. Untuk informasi lebih lanjut, lihat Tingkatkan atau turunkan konfigurasi node pekerja.
`x node(s) didn't match node selector.` `x node(s) didn't match pod affinity/anti-affinity.`	Kluster tidak memiliki node yang sesuai dengan aturan afinitas node (nodeSelector) atau aturan afinitas dan anti-afinitas (podAffinity dan podAntiAffinity) dari pod.	Periksa dan ubah aturan afinitas node pod, termasuk label node, nodeSelector, nodeAffinity, taints, dan tolerations. Periksa dan ubah aturan afinitas pod dari pod. Evaluasi apakah node dapat sesuai dengan aturan afinitas pod. Jika podAffinity dikonfigurasikan, periksa pod yang sesuai dengan podAffinity di node yang diinginkan. Jika podAntiAffinity dikonfigurasikan, periksa pod yang sesuai dengan podAntiAffinity di node yang diinginkan.
`0/x nodes are available: x node(s) had volume node affinity conflict.`	Volume yang digunakan oleh pod mengalami konflik afinitas node karena volume disk tidak dapat dipasang lintas zona. Akibatnya, pod gagal dijadwalkan.	Jika pod menggunakan Persistent Volume (PV) yang diatur secara statis dan Anda ingin menjadwalkan pod ke node di zona PV, Anda harus mengonfigurasikan aturan afinitas node untuk pod. Jika pod menggunakan PV yang diatur secara dinamis, Anda harus mengatur volumeBindingMode dalam StorageClass volume disk menjadi WaitForFirstConsumer. Dengan cara ini, volume hanya dibuat setelah pod dijadwalkan ke node. Ini memastikan bahwa volume berada di zona node yang menampung pod.
`InvalidInstanceType.NotSupportDiskCategory`	Jenis disk tidak didukung oleh Instance Elastic Compute Service (ECS).	Lihat Ikhtisar Keluarga Instance dan periksa jenis disk yang didukung oleh instance ECS. Pasang disk yang didukung oleh instance ECS ke pod.
`0/x nodes are available: x node(s) had taints that the pod didn't tolerate.`	Pod gagal dijadwalkan ke node yang diinginkan karena node memiliki taint.	Jika taint ditambahkan secara manual oleh Anda, hapus taint tersebut. Jika taint harus dipertahankan, Anda dapat menambahkan toleration ke pod. Untuk informasi lebih lanjut, lihat Taints and Tolerations dan Kelola label node dan taint. Jika taint ditambahkan oleh sistem, lihat solusi berikut dan tunggu penjadwal untuk menjadwalkan ulang pod. Lihat taint yang ditambahkan oleh sistem `node.kubernetes.io/not-ready`: Node berada dalam keadaan NotReady. `node.kubernetes.io/unreachable`: Pengontrol node gagal mengakses node. Nilai bidang `Ready` node adalah `Unknown`. `node.kubernetes.io/memory-pressure`: Node tidak memiliki sumber daya memori yang cukup. `node.kubernetes.io/disk-pressure`: Node tidak memiliki ruang disk yang cukup. `node.kubernetes.io/pid-pressure`: Node tidak memiliki ID proses (PID) yang cukup. `node.kubernetes.io/network-unavailable`: Jaringan node tidak tersedia. `node.kubernetes.io/unschedulable`: Node berada dalam keadaan Unschedulable.
`0/x nodes are available: x Insufficient ephemeral-storage.`	Node tidak memiliki ruang penyimpanan sementara yang cukup.	Periksa apakah pod memiliki batas pada volume sementara, yang ditentukan dalam `spec.containers.resources.request.ephemeral-storage` file YAML pod. Jika nilainya melebihi kapasitas penyimpanan sementara node, pod gagal dijadwalkan. Jalankan perintah `kubectl describe node \| grep -A10 Capacity` untuk melihat total ruang penyimpanan sementara semua node. Jika ruang penyimpanan tidak memenuhi kebutuhan Anda, perluas disk node atau tambahkan node.
`0/x nodes are available: pod has unbound immediate PersistentVolumeClaims.`	Persistent Volume Claim (PVC) gagal terikat ke pod.	Periksa apakah PVC atau PV yang ditentukan untuk pod telah dibuat. Anda dapat menjalankan perintah `kubectl describe pvc <pvc-name>` atau `kubectl describe pv <pv-name>` untuk melihat peristiwa PVC atau PV. Untuk informasi lebih lanjut, lihat Mengapa sistem menghasilkan peristiwa "0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims" untuk pod?

Pod sudah dijadwalkan ke node

Jika pod sudah dijadwalkan ke node tetapi tetap dalam keadaan Pending, lihat solusi berikut.

Periksa apakah pod dikonfigurasikan dengan hostPort: Jika pod dikonfigurasikan dengan hostPort, hanya satu pod yang menggunakan hostPort yang dapat berjalan di setiap node. Oleh karena itu, nilai Replicas dalam Deployment atau ReplicationController tidak boleh melebihi jumlah node dalam kluster. Jika port host node digunakan oleh aplikasi lain, pod gagal dijadwalkan ke node.
Pengaturan hostPort meningkatkan kompleksitas manajemen dan penjadwalan pod. Kami merekomendasikan agar Anda menggunakan Services untuk mengakses pod. Untuk informasi lebih lanjut, lihat Services.
Jika pod tidak dikonfigurasikan dengan hostPort, lakukan langkah-langkah berikut.
1. Jalankan perintah kubectl describe pod <pod-name> untuk melihat peristiwa pod dan memecahkan masalah. Peristiwa mungkin menampilkan penyebab kegagalan startup pod, seperti kegagalan penarikan gambar, sumber daya tidak mencukupi, batasan karena kebijakan keamanan, atau kesalahan konfigurasi.
2. Jika Anda gagal menemukan penyebab dalam peristiwa, periksa log kubelet di node. Anda dapat menjalankan perintah grep -i <pod name> /var/log/messages* | less untuk memeriksa entri log yang berisi nama pod dalam file log sistem (/var/log/messages*).

Fase 2: Masalah Penarikan Gambar

Pesan Kesalahan	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 dikonfigurasikan untuk pod.	Periksa apakah Secret yang ditentukan dalam parameter `spec.template.imagePullSecrets` file YAML pod ada. Jika Container Registry digunakan, Anda dapat menggunakan komponen aliyun-acr-credential-helper untuk menarik gambar tanpa kata sandi. Untuk informasi lebih lanjut, lihat Gunakan komponen aliyun-acr-credential-helper untuk menarik gambar tanpa menggunakan secret.
`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`	Gagal mengurai alamat gambar saat menarik gambar dari repositori gambar yang ditentukan melalui HTTP.	Periksa apakah alamat repositori gambar yang ditentukan dalam parameter `spec.containers.image` file YAML pod benar. Jika tidak, revisi alamat repositori gambar. Jika alamat benar, periksa apakah node pod terhubung ke jaringan repositori gambar. Lihat Metode untuk terhubung ke instance ECS dan masuk ke node pod, dan jalankan perintah `curl -kv https://xxxxxx/xxxxx/` untuk memeriksa apakah node dapat mengakses repositori gambar. Jika terjadi kesalahan, periksa konfigurasi jaringan, aturan firewall, dan konfigurasi DNS untuk masalah akses jaringan.
`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 tidak memiliki ruang disk yang cukup.	Lihat Metode untuk terhubung ke instance ECS dan masuk ke node pod, dan jalankan perintah `df -h` untuk melihat ruang disk. Jika ruang disk habis, perluas disk. Untuk informasi lebih lanjut, lihat Langkah 1: Ubah ukuran disk untuk memperluas kapasitas disk.
`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 dan diterbitkan oleh otoritas sertifikat yang tidak dikenal atau tidak tepercaya.	Kami merekomendasikan agar Anda menggunakan sertifikat yang ditandatangani dan diterbitkan oleh otoritas sertifikat tepercaya. Periksa apakah gambar ditarik dari repositori gambar pribadi. Untuk informasi lebih lanjut, lihat Buat aplikasi dari repositori gambar pribadi. Jika Anda tidak dapat mengubah repositori gambar, lihat prosedur berikut dan konfigurasikan node untuk menggunakan sertifikat yang tidak tepercaya untuk menarik dan mendorong gambar ke repositori gambar. Kami merekomendasikan agar Anda menggunakan metode ini di lingkungan staging karena metode ini dapat memengaruhi pod lain di node. Lihat Prosedur Buat direktori sertifikat untuk containerd untuk menyimpan file konfigurasi sertifikat yang terkait dengan repositori gambar. `$ mkdir -p /etc/containerd/cert.d/xxxxx` Konfigurasikan containerd untuk mempercayai repositori gambar. `$ cat << EOF > /etc/containerd/cert.d/xxxxx/hosts.toml server = "https://harbor.test-cri.com" [host."https://harbor.test-cri.com"] capabilities = ["pull", "resolve", "push"] skip_verify = true # ca = "/opt/ssl/ca.crt" # Anda juga dapat mengunggah sertifikat CA. EOF` Tambahkan repositori gambar yang tidak tepercaya ke konfigurasi daemon Docker. `vi /etc/docker/daemon.json` Tambahkan konten berikut. Ganti `your-insecure-registry` dengan alamat repositori gambar yang tidak tepercaya. `{ "insecure-registries": ["your-insecure-registry"] }` Mulai ulang layanan agar modifikasi berlaku. `systemctl restart systemd systemctl restart docker`
`Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled`	Operasi dibatalkan karena file gambar terlalu besar. Kubernetes memiliki batas waktu default untuk penarikan gambar. Jika kemajuan penarikan gambar tidak diperbarui dalam periode waktu tertentu, Kubernetes menganggap terjadi kesalahan atau tidak ada respons yang dikembalikan dan kemudian membatalkan operasi.	Periksa apakah parameter `imagePullPolicy` dalam file YAML pod diatur ke `IfNotPresent`. Lihat Metode untuk terhubung ke instance ECS dan masuk ke node pod, dan jalankan perintah `docker pull` atau `ctr images pull` untuk memeriksa apakah gambar dapat berhasil 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)`	Gagal terhubung ke repositori gambar.	Lihat Metode untuk terhubung ke instance ECS dan masuk ke node pod, dan jalankan perintah `curl https://xxxxxx/xxxxx/` untuk memeriksa apakah alamat repositori gambar dapat diakses. Jika terjadi kesalahan, periksa konfigurasi jaringan, aturan firewall, dan konfigurasi DNS untuk masalah akses jaringan. Periksa apakah kebijakan akses internet node dikonfigurasikan sesuai harapan. Misalnya, periksa entri Source Network Address Translation (SNAT) dan EIP.
`Too Many Requests.`	DockerHub menetapkan batas laju pada permintaan penarikan gambar.	Unggah gambar ke Container Registry dan tarik gambar dari Container Registry.
`Pulling image` terus ditampilkan	Batas atas penarikan gambar menggunakan kubelet mungkin telah tercapai.	Lihat Sesuaikan parameter kubelet dari pool node dan ubah QPS maksimum repositori gambar (registryPullQPS) dan ukuran maksimum burst penarikan gambar (registryBurst).

Fase 3: Masalah Startup

Pod dalam keadaan Init

Pesan Kesalahan	Deskripsi	Solusi yang Disarankan
Pod tetap dalam keadaan `Init:N/M`	Pod berisi M kontainer Init. N kontainer telah dimulai. M-N kontainer Init belum dimulai.	Jalankan perintah `kubectl describe pod -n <ns> <pod name>` untuk melihat peristiwa pod. Pastikan tidak ada anomali pada kontainer Init yang belum dimulai. Jalankan perintah `kubectl logs -n <ns> <pod name> -c <container name>` untuk melihat log kontainer Init yang belum dimulai di pod dan pecahkan masalah berdasarkan data log. Periksa apakah konfigurasi kontainer Init dalam konfigurasi pod mengandung kesalahan, seperti konfigurasi pemeriksaan kesehatan. Untuk informasi lebih lanjut tentang kontainer init, lihat Debug kontainer init.
Pod tetap dalam keadaan `Init:Error`	Kontainer Init dalam pod gagal dimulai.
Pod tetap dalam keadaan `Init:CrashLoopBackOff`	Kontainer Init dalam pod gagal dimulai dan terus-menerus restart.

Pod sedang dibuat (Creating)

Pesan Kesalahan	Deskripsi	Solusi yang Disarankan
`failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx`	Kesalahan ini diharapkan karena desain plugin jaringan Flannel.	Perbarui Flannel ke v0.15.1.11-7e95fe23-aliyun atau versi lebih baru. Untuk informasi lebih lanjut, lihat Flannel.
	Jika kluster menjalankan versi Kubernetes lebih lama dari 1.20 dan pod terus-menerus restart atau pod yang dibuat oleh CronJob menyelesaikan tugas dan keluar setelah periode waktu singkat, kebocoran IP mungkin terjadi.	Perbarui versi Kubernetes kluster ke 1.20 atau lebih baru. Kami merekomendasikan agar Anda memperbarui ke versi terbaru. Untuk informasi lebih lanjut, lihat Tingkatkan Kluster ACK secara Manual.
	containerd dan runC memiliki cacat.	Untuk informasi lebih lanjut, lihat Apa yang harus saya lakukan jika pod gagal dimulai dan muncul pesan kesalahan "no IP addresses available in range"?
`error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found`	Status basis data internal yang dikelola oleh Terway dan digunakan untuk melacak dan mengelola elastic network interfaces (ENI) pada node pod tidak konsisten dengan konfigurasi perangkat jaringan aktual. Akibatnya, ENI gagal dialokasikan.	ENI dimuat secara asinkron. Saat Anda mengonfigurasi CNI, sistem mungkin masih memuat ENI. Hal ini dapat menyebabkan CNI mencoba kembali alokasi ENI. Ini tidak memengaruhi hasil akhir alokasi ENI. Anda dapat menentukan apakah operasi berhasil berdasarkan status akhir pod. Jika pod gagal dibuat untuk waktu yang lama dan kesalahan sebelumnya dilemparkan, driver gagal dimuat selama pemasangan ENI karena kekurangan memori tingkat tinggi. Untuk mengatasi masalah ini, mulai ulang instance ECS yang sesuai. Untuk informasi lebih lanjut, lihat Mulai Ulang Instance.
`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`	Terway gagal meminta alamat IP dari vSwitch.	Lihat log kontainer pod Terway pada node yang menampung pod dan periksa proses alokasi ENI. Jalankan perintah `kubectl logs -n kube-system <terwayPodName> -c terway \| grep <podName>` untuk melihat informasi ENI pod Terway. Dapatkan ID permintaan operasi yang dilakukan untuk meminta alamat IP dan pesan kesalahan yang dikembalikan oleh API. Tentukan penyebab berdasarkan ID permintaan dan pesan kesalahan.

Pod gagal memulai (CrashLoopBackOff)

Pesan Kesalahan	Deskripsi	Solusi yang Disarankan
Log menampilkan `exit(0)`.		Masuk ke node tempat beban kerja abnormal diterapkan. Jalankan perintah `docker ps -a \| grep $podName`. Jika tidak ada proses persisten di pod, `exit (0)` akan ditampilkan.
Informasi peristiwa menampilkan `Liveness probe failed: Get http…`.	Kegagalan pemeriksaan kesehatan terjadi.	Periksa kebijakan pemeriksaan liveness pod. Pastikan hasil pemeriksaan liveness dapat menunjukkan status aktual aplikasi yang berjalan di kontainer pod.
Log pod menampilkan `no left space`.	Ruang disk tidak mencukupi.	Lihat Langkah 1: Ubah ukuran disk untuk memperluas kapasitas disk dan perluas disk. Hapus gambar yang tidak digunakan untuk membebaskan ruang disk dan konfigurasikan imageGCHighThresholdPercent untuk menyesuaikan ambang batas pemicu pengumpulan sampah gambar di node.
Pod gagal memulai dan tidak ada peristiwa yang dihasilkan	Batas sumber daya pod lebih rendah daripada sumber daya yang diminta oleh pod. Akibatnya, kontainer dalam pod gagal memulai.	Periksa konfigurasi sumber daya pod. Anda dapat mengaktifkan profil sumber daya untuk mendapatkan permintaan sumber daya yang disarankan dan batas sumber daya.
Log pod menampilkan `Address already in use`.	Kontainer dalam pod mengalami konflik port.	Periksa apakah `hostNetwork: true` dikonfigurasikan untuk pod. Jika ya, kontainer dalam pod berbagi ENI dan port dengan host. Jika Anda tidak ingin menggunakan jaringan host, tentukan `hostNetwork: false`. Jika `hostNetwork: true` dikonfigurasikan, konfigurasikan aturan anti-afinitas pod untuk memastikan bahwa pod dari set replika yang sama tidak dijadwalkan ke node yang sama. Pastikan bahwa pod yang menggunakan port yang sama tidak dijadwalkan ke node yang sama.
Log pod menampilkan `container init caused \"setenv: invalid argument\"": unknown`.	Beban kerja dipasang dengan Secret. Nilai kunci Secret tidak dienkripsi menggunakan Base64.	Nilai kunci Secret yang dibuat di konsol secara otomatis dienkripsi menggunakan Base64. Untuk informasi lebih lanjut, lihat Kelola Secrets. Gunakan YAML untuk membuat Secret dan jalankan perintah `echo -n "xxxxx" \| base64` untuk mengenkripsi nilai kunci menggunakan Base64.
Masalah bisnis ada.		Tentukan penyebab berdasarkan log pod.

Fase 4: Masalah Operasi Pod

OOM

Jika penggunaan memori kontainer dalam kluster melebihi batas memori yang ditentukan, kontainer mungkin dihentikan dan memicu peristiwa OOM, yang menyebabkan kontainer keluar. Untuk informasi lebih lanjut tentang peristiwa OOM, lihat Alokasikan sumber daya memori ke kontainer dan pod.

Jika proses yang dihentikan menyebabkan kontainer macet, kontainer mungkin restart.
Jika terjadi kesalahan OOM, masuk ke konsol dan navigasikan ke halaman detail pod. Di tab Events, Anda dapat melihat peristiwa OOM berikut: pod was OOM killed.
Jika kluster dikonfigurasikan dengan aturan peringatan untuk pengecualian replika kontainer, Anda akan menerima peringatan saat peristiwa OOM terjadi. Untuk informasi lebih lanjut, lihat Manajemen Peringatan.

Level OOM	Deskripsi	Solusi yang Disarankan
Level OS	Log kernel (`/var/log/messages`) dari node yang menampung pod menampilkan proses yang dihentikan tetapi tidak ada log cgroup yang dihasilkan. Ini berarti kesalahan OOM adalah level OS.	Penyebab yang mungkin adalah kekurangan memori global sistem, kekurangan memori node, atau kekurangan memori sistem buddy selama fragmentasi memori. Untuk informasi lebih lanjut tentang penyebab kekurangan memori, lihat Kemungkinan Penyebab. Untuk informasi lebih lanjut tentang solusi, lihat Solusi.
Level cgroup	Log kernel (`/var/log/messages`) dari node yang menampung pod menampilkan pesan kesalahan serupa dengan `Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx`. Ini berarti kesalahan OOM adalah level cgroup.	Jika proses berjalan normal, tingkatkan batas memori pod sesuai. Pastikan penggunaan memori aktual pod tidak melebihi 80% dari batas memori. Untuk informasi lebih lanjut, lihat Ubah batas atas dan bawah sumber daya CPU dan memori untuk pod. Anda dapat mengaktifkan profil sumber daya untuk mendapatkan permintaan sumber daya yang disarankan dan batas sumber daya untuk kontainer.

Terminating

Penyebab yang Mungkin	Deskripsi	Solusi yang Disarankan
Node tidak normal dan dalam keadaan NotReady.		Node NotReady secara otomatis dihapus setelah pulih.
Finalizers dikonfigurasikan untuk pod.	Jika finalizers dikonfigurasikan untuk pod, Kubernetes melakukan operasi pembersihan yang ditentukan oleh finalizers sebelum menghapus pod. Jika tidak ada respons yang dikembalikan untuk operasi pembersihan, pod tetap dalam keadaan Terminating.	Jalankan perintah `kubectl get pod -n <ns> <pod name> -o yaml` untuk melihat konfigurasi finalizer pod dan tentukan penyebabnya.
Hooks preStop pod tidak valid.	Jika hooks preStop dikonfigurasikan untuk pod, Kubernetes melakukan operasi yang ditentukan oleh hooks preStop sebelum menghentikan pod. Pod berada pada tahap preStop dan akan memasuki keadaan Terminating.	Jalankan perintah `kubectl get pod -n <ns> <pod name> -o yaml` untuk melihat konfigurasi preStop pod dan tentukan penyebabnya.
Pod dikonfigurasikan dengan periode shutdown yang aman.	Jika pod dikonfigurasikan dengan periode shutdown yang aman (`terminationGracePeriodSeconds`), pod memasuki keadaan Terminating setelah menerima perintah terminasi, seperti `kubectl delete pod <pod_name>`. Kubernetes menganggap bahwa pod telah dihentikan setelah periode shutdown yang aman (`terminationGracePeriodSeconds`) berakhir atau semua kontainer dalam pod keluar sebelum periode shutdown yang aman berakhir.	Setelah kontainer keluar dengan aman, Kubernetes menghapus pod.
Kontainer tidak merespons.	Setelah Anda memulai permintaan untuk menghentikan atau menghapus pod, Kubernetes mengirim sinyal `SIGTERM` ke kontainer dalam pod. Jika kontainer tidak merespons sinyal `SIGTERM`, pod mungkin tetap dalam keadaan Terminating.	Jalankan perintah `kubectl delete pod <pod-name> --grace-period=0 --force` untuk memaksa menghapus pod. Periksa log containerd atau Docker dari node yang menampung pod dan tentukan penyebabnya.

Evicted

Penyebab yang Mungkin	Deskripsi	Solusi yang Disarankan
Node tidak memiliki sumber daya yang cukup, seperti memori atau ruang disk. Akibatnya, kubelet mengusir satu atau lebih pod di node untuk mereklaim sumber daya.	Node mungkin tidak memiliki memori, ruang disk, atau PIDs yang cukup. Jalankan perintah `kubectl describe node <node name> \| grep Taints` untuk menanyakan taint node. Kekurangan memori: Node memiliki taint `node.kubernetes.io/memory-pressure`. Kekurangan ruang disk: Node memiliki taint `node.kubernetes.io/disk-pressure`. Kekurangan PIDs: Node memiliki taint `node.kubernetes.io/pid-pressure`.	Kekurangan memori: Atur konfigurasi sumber daya pod. Untuk informasi lebih lanjut, lihat Manage pods. Tingkatkan node. Untuk informasi lebih lanjut, lihat Tingkatkan atau turunkan konfigurasi dari sebuah worker node. Kekurangan ruang disk: Hapus log aplikasi pod secara berkala pada node. Perluas disk node. Untuk informasi lebih lanjut, lihat Langkah 1: Ubah ukuran disk untuk memperluas kapasitas disk. Kekurangan PIDs: Ubah pengaturan sumber daya pod. Untuk informasi lebih lanjut, lihat Batas dan Reservasi Process ID.
Pengusiran yang tidak terduga terjadi.	Node yang menampung pod memiliki taint NoExecute. Akibatnya, pengusiran yang tidak terduga terjadi.	Jalankan perintah `kubectl describe node <node name> \| grep Taints` untuk memeriksa apakah node memiliki taint NoExecute. Jika ya, hapus taint tersebut.
Pod tidak diusir sesuai harapan.	`--pod-eviction-timeout`: periode timeout pengusiran pod. Ketika downtime node melebihi periode timeout yang ditentukan, pod diusir dari node. Timeout default adalah 5 menit. `--node-eviction-rate`: jumlah pod yang diusir per detik. Defaultnya adalah 0.1, yang berarti setidaknya satu pod diusir dari node setiap 10 detik. `--secondary-node-eviction-rate`: laju pengusiran pod sekunder. Jika sejumlah besar node mati, pengusiran pod disesuaikan ke laju sekunder. Nilai default adalah 0.01. `--unhealthy-zone-threshold`: ambang batas zona tidak sehat. Nilai default adalah 0.55. Ketika jumlah node yang gagal melebihi 55% dari total jumlah node, zona dianggap tidak sehat. `--large-cluster-size-threshold`: ambang batas kluster besar. Nilai default adalah 50. Ketika jumlah node kluster melebihi 50, kluster dianggap sebagai kluster besar.	Dalam kluster kecil yang berisi tidak lebih dari 50 node, jika lebih dari 55% node mati, pengusiran pod dihentikan. Untuk informasi lebih lanjut, lihat Batas Laju pada Pengusiran.
Pod tidak diusir sesuai harapan.		Dalam kluster besar yang berisi lebih dari 50 node, jika rasio node tidak sehat terhadap total node melebihi nilai `--unhealthy-zone-threshold` (defaultnya adalah 0.55), laju pengusiran diatur ke nilai `--secondary-node-eviction-rate`. Parameter ini menentukan proporsi maksimum pod yang diusir per menit. Nilai defaultnya adalah 0.01. Untuk informasi lebih lanjut, lihat Batas Laju pada Pengusiran.
Pod masih sering dijadwalkan ke node aslinya setelah diusir.	Pod diusir dari node berdasarkan penggunaan sumber daya node. Aturan penjadwalan pod bergantung pada sumber daya yang dialokasikan pada node. Pod yang diusir mungkin dijadwalkan kembali ke node aslinya.	Periksa apakah permintaan sumber daya pod dikonfigurasikan dengan benar berdasarkan sumber daya yang dapat dialokasikan pada node. Untuk informasi lebih lanjut, lihat Ubah batas atas dan bawah sumber daya CPU dan memori untuk pod. Anda dapat mengaktifkan profil sumber daya untuk mendapatkan permintaan sumber daya yang disarankan dan batas sumber daya untuk kontainer.

Completed

Ketika pod dalam keadaan Completed, semua kontainer dalam pod telah dimulai dan semua proses dalam kontainer telah berhasil keluar. Keadaan Completed biasanya cocok untuk Job dan kontainer Init.

Pertanyaan yang Sering Diajukan Lainnya

Pod tetap dalam keadaan Running tetapi tidak berjalan normal

Jika file YAML pod mengandung kesalahan, pod mungkin tetap dalam keadaan Running tetapi tidak berjalan normal. Untuk mengatasi masalah ini, lakukan langkah-langkah berikut.

Periksa konfigurasi pod dan periksa apakah kontainer dalam pod dikonfigurasikan sesuai harapan.
Gunakan metode berikut untuk memeriksa apakah kunci variabel lingkungan mengandung kesalahan ejaan.
Jika kunci variabel lingkungan mengandung kesalahan ejaan, misalnya, command dieja sebagai commnd, kluster dapat mengabaikan kesalahan ejaan dan membuat pod berdasarkan file YAML. Namun, kontainer tidak dapat menjalankan perintah yang ditentukan dalam file YAML.
Contoh berikut menjelaskan cara mengidentifikasi kesalahan ejaan jika Anda mengeja command sebagai commnd.
1. Tambahkan --validate sebelum perintah kubectl apply -f dan jalankan perintah kubectl apply --validate -f XXX.yaml.
  Jika ada kesalahan ejaan, pesan XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test akan ditampilkan.
2. Jalankan perintah berikut untuk membandingkan file pod.yaml yang Anda periksa dengan file YAML yang digunakan untuk membuat pod.
  Catatan
  Ganti [$Pod] dengan nama pod abnormal. Anda dapat menjalankan perintah kubectl get pods untuk mendapatkan nama.
```
  kubectl get pods [$Pod] -o yaml > pod.yaml
```
  - Jika file pod.yaml berisi lebih banyak baris daripada file YAML asli yang digunakan untuk membuat pod, ini berarti pod dibuat sesuai harapan.
  - Jika baris perintah YAML untuk membuat pod tidak ditemukan dalam file pod.yaml, ini berarti file YAML asli mengandung kesalahan ejaan.
Periksa log pod dan pecahkan masalah berdasarkan data log.
Anda dapat masuk ke kontainer pod menggunakan terminal dan periksa file lokal dalam kontainer.

Masalah pemutusan jaringan kadang-kadang terjadi ketika pod mengakses database

Jika masalah pemutusan jaringan kadang-kadang terjadi ketika pod dalam kluster ACK mengakses database, Anda dapat melakukan operasi berikut untuk memecahkan masalah.

1. Periksa pod

Lihat peristiwa pod dan periksa peristiwa koneksi tidak stabil, seperti peristiwa terkait pengecualian jaringan, restart, dan sumber daya tidak mencukupi.
Lihat log pod dan periksa kesalahan koneksi database, seperti waktu habis koneksi, kegagalan autentikasi, atau rekoneksi.
Lihat penggunaan CPU dan memori pod. Pastikan aplikasi atau driver database tidak keluar secara tidak normal karena sumber daya tidak mencukupi.
Lihat permintaan sumber daya dan batas pod. Pastikan pod memiliki sumber daya CPU dan memori yang cukup.

2. Periksa node

Periksa penggunaan sumber daya node dan pastikan sumber daya seperti memori dan ruang disk mencukupi. Untuk informasi lebih lanjut, lihat Pantau node.
Uji apakah pemutusan jaringan kadang-kadang terjadi antara node dan database.

3. Periksa database

Periksa status dan metrik performa database untuk memastikan tidak ada restart atau hambatan performa.
Lihat jumlah koneksi abnormal dan periksa pengaturan periode timeout, serta ubah pengaturan berdasarkan kebutuhan bisnis Anda.
Analisis log database terkait pemutusan dari database.

4. Periksa status komponen kluster

Penyimpangan komponen kluster memengaruhi komunikasi antara pod dan komponen lain dalam kluster. Jalankan perintah berikut untuk memeriksa status komponen dalam kluster ACK:

kubectl get pod -n kube-system  # Lihat status komponen.

Periksa komponen jaringan:

CoreDNS: Periksa status dan log komponen. Pastikan pod dapat mengurai alamat layanan database.
Flannel: Periksa status dan log kube-flannel.
Terway: Periksa status dan log terway-eniip.

5. Analisis lalu lintas jaringan

Anda dapat menggunakan tcpdump untuk menangkap paket dan menganalisis lalu lintas jaringan untuk membantu menemukan penyebabnya.

Jalankan perintah berikut untuk mengidentifikasi pod dan node tempat masalah pemutusan database terjadi.
```
kubectl  get pod -n [namespace] -o wide 
```
Masuk ke node. Untuk informasi lebih lanjut, lihat Metode untuk terhubung ke instance ECS.
Jalankan perintah berikut untuk menanyakan PID kontainer berdasarkan versi Kubernetes yang berbeda.
containerd (Versi Kubernetes lebih baru dari 1.22)
1. Jalankan perintah berikut untuk melihat CONTAINER:
```
crictl ps |grep <Nama Pod atau kata kunci>
```
  Output yang Diharapkan:
```
CONTAINER           IMAGE               CREATED             STATE                      
a1a214d2*****       35d28df4*****       2 days ago          Running
```
2. Tentukan parameter CONTAINER ID dan jalankan perintah berikut untuk melihat PID kontainer:
```
crictl inspect  a1a214d2***** |grep -i PID
```
  Output yang Diharapkan:
```
"pid": 2309838, # PID kontainer. 
            "pid": 1
            "type": "pid"
```
Docker (Kubernetes 1.22 dan sebelumnya)
1. Jalankan perintah berikut untuk melihat CONTAINER ID:
```
docker ps | grep <Nama Pod atau kata kunci>
```
  Output yang Diharapkan:
```
CONTAINER ID        IMAGE                  COMMAND     
a1a214d2*****       35d28df4*****          "/nginx
```
2. Tentukan parameter CONTAINER ID dan jalankan perintah berikut untuk melihat PID kontainer:
```
docker inspect  a1a214d2***** |grep -i PID
```
  Output yang Diharapkan:
```
"Pid": 2309838, # PID kontainer. 
            "PidMode": "",
            "PidsLimit": null,
```
Jalankan perintah penangkapan paket.
Jalankan perintah berikut berdasarkan PID kontainer untuk menangkap paket yang ditransmisikan antara pod dan database:
```
nsenter -t <Container PID> tcpdump -i any -n -s 0 tcp and host <Alamat IP database>
```
Jalankan perintah berikut berdasarkan PID kontainer untuk menangkap paket yang ditransmisikan antara pod dan host:
```
nsenter -t <Container PID> tcpdump -i any -n -s 0 tcp and host <Alamat IP node>
```
Jalankan perintah berikut untuk menangkap paket yang ditransmisikan antara host dan database.
```
tcpdump -i any -n -s 0 tcp and host <Alamat IP database>
```

6. Optimalkan aplikasi

Konfigurasikan aplikasi Anda untuk mendukung mekanisme rekoneksi otomatis, memastikan aplikasi dapat memulihkan koneksi secara otomatis tanpa intervensi manual ketika database diubah atau dipindahkan.
Gunakan koneksi persisten alih-alih koneksi singkat untuk berkomunikasi dengan database. Koneksi persisten dapat secara signifikan mengurangi kerugian performa dan konsumsi sumber daya, serta meningkatkan efisiensi sistem secara keseluruhan.

Memecahkan Masalah di Konsol

Anda dapat masuk ke Konsol ACK, navigasikan ke halaman detail kluster, dan kemudian pecahkan masalah pod abnormal.

Operasi	Tata letak konsol
Periksa status pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di sudut kiri atas halaman Pods, pilih namespace tempat pod berada dan periksa status pod. Jika pod dalam keadaan Running, pod berjalan sesuai harapan. Jika pod tidak dalam keadaan Running, pod tidak normal. Untuk memecahkan masalah, baca topik ini.
Periksa informasi dasar pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di sudut kiri atas halaman Pods, pilih namespace tempat pod berada. Dalam daftar pod, temukan pod dan klik nama pod atau klik Lihat Detail di kolom Tindakan untuk melihat informasi tentang pod. Anda dapat melihat nama, gambar, dan alamat IP pod serta node yang menampung pod.
Periksa konfigurasi pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di sudut kiri atas halaman Pods, pilih namespace tempat pod berada. Dalam daftar pod, temukan pod dan klik nama pod atau klik Lihat Detail di kolom Tindakan. Di sudut kanan atas halaman detail pod, klik Edit untuk melihat file YAML dan konfigurasi pod.
Periksa peristiwa pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di sudut kiri atas halaman Pods, pilih namespace tempat pod berada. Dalam daftar pod, temukan pod dan klik nama pod atau klik Lihat Detail di kolom Tindakan. Di bagian bawah halaman detail pod, klik tab Events untuk melihat peristiwa pod. Catatan Secara default, Kubernetes menyimpan peristiwa yang terjadi dalam satu jam terakhir. Jika Anda ingin menyimpan peristiwa yang terjadi dalam periode waktu yang lebih lama, lihat Buat dan gunakan pusat peristiwa.
Periksa log pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di sudut kiri atas halaman Pods, pilih namespace tempat pod berada. Dalam daftar pod, temukan pod dan klik nama pod atau klik Lihat Detail di kolom Tindakan. Di bagian bawah halaman detail pod, klik tab Logs untuk melihat data log pod. Catatan Kluster ACK diintegrasikan dengan Layanan Log Sederhana. Anda dapat mengaktifkan Layanan Log Sederhana untuk kluster Anda untuk dengan cepat mengumpulkan log kontainer. Untuk informasi lebih lanjut, lihat Kumpulkan log kontainer dari kluster ACK.
Periksa informasi pemantauan pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Operations > Prometheus Monitoring. Di halaman Prometheus Monitoring, klik tab Cluster Overview untuk melihat informasi pemantauan berikut tentang pod: penggunaan CPU, penggunaan memori, dan jaringan I/O. Catatan Kluster ACK diintegrasikan dengan Managed Service for Prometheus. Anda dapat mengaktifkan Managed Service for Prometheus untuk kluster ACK untuk memantau kluster dan kontainer dalam kluster secara real-time. Setelah Anda mengaktifkan Managed Service for Prometheus, Anda dapat melihat metrik yang ditampilkan pada dasbor Grafana. Untuk informasi lebih lanjut, lihat Gunakan Managed Service for Prometheus.
Masuk ke kontainer pod menggunakan terminal dan lihat file lokal dalam kontainer	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di halaman Pods, temukan pod yang ingin Anda kelola dan klik Terminal di kolom Actions.
Aktifkan diagnostik pod	Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Workloads > Pods. Di halaman Pods, temukan pod yang ingin Anda diagnosis dan klik Diagnose di kolom Actions. Catatan Container Intelligent Service menyediakan fitur diagnostik kluster untuk memungkinkan Anda mendiagnosis pod, Layanan, dan Ingress dengan satu klik dan membantu Anda menemukan penyebabnya. Untuk informasi lebih lanjut, lihat Bekerja dengan diagnostik kluster.