Memecahkan masalah runtime container

---

Dokumen ini berisi langkah-langkah pemecahan masalah untuk masalah umum yang mungkin Anda alami dengan runtime container di node Google Kubernetes Engine (GKE).

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.

Jalur pemasangan dengan huruf drive sederhana gagal di kumpulan node Windows dengan container

Masalah ini telah diatasi pada container versi 1.6.6 dan yang lebih baru.

Cluster GKE yang menjalankan kumpulan node Windows Server yang menggunakan runtime dalam container sebelum versi 1.6.6 mungkin mengalami error saat memulai container seperti berikut:

failed to create containerd task : CreateComputeSystem : The parameter is incorrect : unknown

Untuk detail selengkapnya, lihat masalah GitHub #6589.

Solusi

Untuk mengatasi masalah ini, upgrade node pool ke versi GKE terbaru yang menggunakan runtime container versi 1.6.6 atau yang lebih baru.

Gambar container dengan command line CMD atau ENTRYPOINT yang di-escape sebelumnya (non-array) gagal di kumpulan node Windows dengan container

Masalah ini telah diatasi pada container versi 1.6 dan yang lebih baru.

Cluster GKE yang menjalankan kumpulan node Windows Server yang menggunakan runtime 1.5.X dalam container mungkin mengalami error saat memulai container seperti berikut:

failed to start containerd task : hcs::System::CreateProcess : The system cannot find the file specified.: unknown

Untuk mengetahui detail selengkapnya, lihat masalah GitHub #5067 dan masalah GitHub #6300.

Solusi

Untuk mengatasi masalah ini, upgrade node pool ke versi GKE terbaru yang menggunakan runtime container versi 1.6.6 atau yang lebih baru.

Volume image container dengan jalur yang tidak ada atau jalur seperti Linux (garis miring) gagal di kumpulan node Windows dengan container

Masalah ini telah diatasi pada container versi 1.6 dan yang lebih baru.

Cluster GKE yang menjalankan kumpulan node Windows Server yang menggunakan runtime 1.5.X dalam container mungkin mengalami error saat memulai container seperti berikut:

failed to generate spec: failed to stat "<volume_path>": CreateFile : The system cannot find the path specified.

Untuk detail selengkapnya, lihat Masalah GitHub #5671.

Solusi

Untuk mengatasi masalah ini, upgrade node pool ke versi GKE terbaru yang menggunakan runtime container versi 1.6.x atau yang lebih baru.

/etc/mtab: File atau direktori tersebut tidak ada

Runtime container Docker mengisi symlink ini di dalam container secara default, tetapi runtime dalam container tidak mengisinya.

Untuk mengetahui detail selengkapnya, lihat Masalah GitHub #2419.

Solusi

Untuk mengatasi masalah ini, buat symlink /etc/mtab secara manual selama proses build image.

ln -sf /proc/mounts /etc/mtab

Error penarikan image: bukan sebuah direktori

Versi GKE yang terpengaruh: semua

Saat Anda mem-build image dengan kaniko, image tersebut mungkin gagal diambil dengan container yang berisi pesan error "not a directory". Error ini terjadi jika gambar dibuat dengan cara khusus: saat perintah sebelumnya menghapus direktori dan perintah berikutnya membuat ulang file yang sama di direktori tersebut.

Contoh Dockerfile berikut dengan npm yang mengilustrasikan masalah ini.

RUN npm cache clean --force
RUN npm install

Untuk detail selengkapnya, lihat Masalah GitHub #4659.

Solusi

Untuk mengatasi masalah ini, buat image menggunakan docker build, yang tidak terpengaruh oleh masalah ini.

Jika docker build tidak tersedia bagi Anda, gabungkan perintah menjadi satu. Contoh Dockerfile berikut menggabungkan RUN npm cache clean --force dan RUN npm install:

RUN npm cache clean --force && npm install

Beberapa metrik sistem file tidak ada dan format metriknya berbeda

Catatan: Masalah ini tidak memengaruhi pelanggan yang menggunakan Cloud Monitoring.

Versi GKE yang terpengaruh: semua

Endpoint /metrics/cadvisor Kubelet menyediakan metrik Prometheus, seperti yang didokumentasikan dalam Metrik untuk komponen sistem Kubernetes. Jika menginstal kolektor metrik yang bergantung pada endpoint tersebut, Anda mungkin melihat masalah berikut:

• Format metrik di node Docker adalah k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>, tetapi format di node containerd adalah <container-id>.

• Beberapa metrik sistem file tidak ada di node container, seperti berikut:

  container_fs_inodes_free
  container_fs_inodes_total
  container_fs_io_current
  container_fs_io_time_seconds_total
  container_fs_io_time_weighted_seconds_total
  container_fs_limit_bytes
  container_fs_read_seconds_total
  container_fs_reads_merged_total
  container_fs_sector_reads_total
  container_fs_sector_writes_total
  container_fs_usage_bytes
  container_fs_write_seconds_total
  container_fs_writes_merged_total
  

Solusi

Anda dapat mengurangi masalah ini dengan menggunakan cAdvisor sebagai daemonset mandiri.

1. Temukan rilis cAdvisor terbaru dengan pola nama vX.Y.Z-containerd-cri (misalnya, v0.42.0-containerd-cri).
2. Ikuti langkah-langkah di Daemonset Kubernetes cAdvisor untuk membuat daemonset.
3. Arahkan kolektor metrik yang diinstal untuk menggunakan endpoint /metrics cAdvisor yang menyediakan kumpulan lengkap metrik container Prometheus.

Alternatif

1. Migrasikan solusi pemantauan Anda ke Cloud Monitoring, yang menyediakan serangkaian metrik container lengkap.
2. Kumpulkan metrik dari summary API Kubelet dengan endpoint /stats/summary.

Operasi berbasis lampiran tidak berfungsi dengan benar setelah runtime container dimulai ulang di Windows GKE

Versi GKE yang terpengaruh: 1.21 hingga 1.21.5-gke.1802, 1.22 hingga 1.22.3-gke.700

Cluster GKE yang menjalankan kumpulan node Windows Server yang menggunakan runtime dalam container (versi 1.5.4 dan 1.5.7-gke.0) mungkin mengalami masalah jika runtime container dimulai ulang secara paksa, dengan operasi pemasangan ke container yang sudah ada dan tidak dapat mengikat IO lagi. Masalah ini tidak akan menyebabkan kegagalan dalam panggilan API, tetapi data tidak akan dikirim atau diterima. Hal ini mencakup data untuk lampiran serta mencatat CLI dan API melalui server API cluster.

Solusi

Untuk mengatasi masalah ini, upgrade ke versi runtime container yang di-patch (1.5.7-gke.1) dengan rilis GKE yang lebih baru.

Pod menampilkan pesan error failed to allocate for range 0: no IP addresses available in range set

Versi GKE yang terpengaruh: 1.24.6-gke.1500 atau sebelumnya, 1.23.14-gke.1800 atau sebelumnya, dan 1.22.16-gke.2000 atau sebelumnya

Cluster GKE yang menjalankan kumpulan node yang menggunakan containerd mungkin mengalami masalah kebocoran IP dan menghabiskan semua IP Pod pada sebuah node. Pod yang dijadwalkan pada node yang terpengaruh akan menampilkan pesan error seperti berikut:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Untuk mengetahui informasi selengkapnya tentang masalah ini, lihat masalah GitHub #5438 dalam container dan masalah GitHub #5768.

Terdapat masalah umum di GKE Dataplane V2 yang dapat memicu masalah ini. Namun, masalah ini dapat dipicu oleh penyebab lain, termasuk runc yang terhenti.

Solusi

Untuk mengatasi masalah ini, ikuti solusi yang disebutkan dalam Solusi untuk cluster GKE Standar untuk GKE Dataplane V2.

Perbedaan perilaku pemeriksaan eksekusi saat pemeriksaan melebihi waktu tunggu

Versi GKE yang terpengaruh: semua

Perilaku pemeriksaan eksekusi pada image containerd berbeda dengan perilaku pada image dockershim. Ketika pemeriksaan eksekutif, yang ditentukan untuk Pod, melebihi batas Kubernetes timeoutSeconds yang dinyatakan, pada image dockershim, pemeriksaan tersebut akan dianggap sebagai kegagalan pemeriksaan. Pada image containerd, hasil pemeriksaan yang ditampilkan setelah batas timeoutSeconds yang dideklarasikan akan diabaikan.

Solusi

Di GKE, gate fitur ExecProbeTimeout disetel ke false dan tidak dapat diubah. Untuk mengatasi masalah ini, tingkatkan nilai minimum timeoutSeconds untuk semua pemeriksaan eksekutif yang terpengaruh atau implementasikan fungsi waktu tunggu sebagai bagian dari logika pemeriksaan.

Memecahkan masalah terkait registry pribadi

Bagian ini memberikan informasi pemecahan masalah untuk konfigurasi registry pribadi dalam container.

Pengambilan image gagal dengan error x509: sertifikat ditandatangani oleh otoritas tidak dikenal

Masalah ini terjadi jika GKE tidak dapat menemukan sertifikat untuk domain registry pribadi tertentu. Anda dapat memeriksa error ini di Cloud Logging menggunakan kueri berikut:

1. Buka halaman Logs Explorer di konsol Google Cloud:

   Buka Logs Explorer

2. Jalankan kueri berikut:

   ("Internal error pulling certificate" OR
   "Failed to get credentials from metadata server" OR
   "Failed to install certificate")
   

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

1. Di GKE Standard, buka file konfigurasi yang ada di jalur berikut:

   /etc/containerd/hosts.d/DOMAIN/config.toml
   

   Ganti DOMAIN dengan FQDN untuk registry.

2. Pastikan file konfigurasi Anda berisi FQDN yang benar.

3. Pastikan jalur ke sertifikat di kolom secretURI dalam file konfigurasi sudah benar.

4. Pastikan sertifikat ada di Secret Manager.

Sertifikat tidak ada

Masalah ini terjadi jika GKE tidak dapat mengambil sertifikat dari Secret Manager untuk mengonfigurasi container pada node Anda.

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

1. Pastikan node yang terpengaruh menjalankan Container-Optimized OS. {i>Node<i} Ubuntu dan Windows tidak didukung.
2. Di file konfigurasi Anda, pastikan jalur ke secret di kolom secretURI sudah benar.
3. Pastikan akun layanan IAM cluster Anda memiliki izin yang benar untuk mengakses secret.
4. Periksa apakah cluster memiliki cakupan akses cloud-platform. Untuk mengetahui petunjuknya, lihat Memeriksa cakupan akses.

Opsi registry tidak aman belum dikonfigurasi untuk jaringan lokal (10.0.0.0/8)

Versi GKE yang terpengaruh: semua

Pada image dalam container, opsi registry yang tidak aman tidak dikonfigurasi untuk jaringan lokal 10.0.0.0/8. Jika menggunakan registry pribadi yang tidak aman, Anda mungkin melihat pesan error seperti berikut:

pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "IMAGE_NAME": failed to do request: Head "IMAGE_NAME": http: server gave HTTP response to HTTPS client

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

• Gunakan Artifact Registry
• Konfigurasikan TLS di registry pribadi jika kasus penggunaan Anda mendukung opsi ini. Anda dapat menggunakan file konfigurasi dalam container untuk memberi tahu GKE agar menggunakan sertifikat yang Anda simpan di Secret Manager untuk mengakses registry pribadi Anda. Untuk mengetahui petunjuknya, lihat Mengakses registry pribadi dengan sertifikat CA pribadi.

Mengonfigurasi DaemonSets dengan hak istimewa untuk mengubah konfigurasi container Anda

Untuk cluster Standar, coba langkah-langkah berikut. Solusi ini tidak tersedia di Autopilot karena container dengan hak istimewa berisiko keamanan. Jika lingkungan Anda terekspos ke internet, pertimbangkan toleransi risiko Anda sebelum men-deploy solusi ini. Dalam semua kasus, kami sangat menyarankan Anda untuk mengonfigurasi TLS untuk registry pribadi Anda dan menggunakan opsi Secret Manager.

Perhatian: Anda perlu memulai ulang containerd untuk melakukan operasi ini, sehingga dapat menyebabkan gangguan pada workload yang sudah berjalan di node.

1. Tinjau manifes berikut:

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: insecure-registries
     namespace: default
     labels:
       k8s-app: insecure-registries
   spec:
     selector:
       matchLabels:
         name: insecure-registries
     updateStrategy:
       type: RollingUpdate
     template:
       metadata:
         labels:
           name: insecure-registries
       spec:
         nodeSelector:
           cloud.google.com/gke-container-runtime: "containerd"
         hostPID: true
         containers:
           - name: startup-script
             image: gcr.io/google-containers/startup-script:v1
             imagePullPolicy: Always
             securityContext:
               privileged: true
             env:
             - name: ADDRESS
               value: "REGISTRY_ADDRESS"
             - name: STARTUP_SCRIPT
               value: |
                 set -o errexit
                 set -o pipefail
                 set -o nounset
   
                 if [[ -z "$ADDRESS" || "$ADDRESS" == "REGISTRY_ADDRESS" ]]; then
                   echo "Error: Environment variable ADDRESS is not set in containers.spec.env"
                   exit 1
                 fi
   
                 echo "Allowlisting insecure registries"
                 grep -qxF '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]' /etc/containerd/config.toml || \
                   echo -e '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]\n  endpoint = ["http://'$ADDRESS'"]' >> /etc/containerd/config.toml
                 echo "Reloading systemd management configuration"
                 systemctl daemon-reload
                 echo "Restarting containerd..."
                 systemctl restart containerd

   Di kolom .spec.containers.env, ganti nilai REGISTRY_ADDRESS dari variabel ADDRESS dengan alamat registry HTTP lokal Anda dalam format DOMAIN_NAME:PORT. Misalnya,

   containers:
   - name: startup-script
     ...
     env:
     - name: ADDRESS
       value: "example.com:5000"
   

2. Deploy DaemonSet:

   kubectl apply -f insecure-registry-ds.yaml
   

DaemonSet menambahkan registry tidak aman Anda ke konfigurasi containerd di setiap node.

containerd mengabaikan pemetaan perangkat untuk pod dengan hak istimewa

Versi GKE yang terpengaruh: semua

Untuk Pod Kubernetes dengan hak istimewa, runtime container mengabaikan pemetaan perangkat apa pun yang diteruskan oleh volumeDevices.devicePath ke sana, dan sebagai gantinya membuat setiap perangkat di host tersedia untuk container dalam /dev.

kebocoran container shim proses ketika node berada di bawah tekanan I/O

Versi GKE yang terpengaruh: 1.25.0 hingga 1.25.15-gke.1040000, 1.26.0 hingga 1.26.10-gke.1030000, 1.27.0 hingga 1.27.6-gke.1513000, dan 1.28.0-gke1.0.30.

Saat node GKE mengalami tekanan I/O, containerd mungkin gagal menghapus proses containerd-shim-runc-v2 saat Pod dihapus, yang mengakibatkan kebocoran proses. Jika terjadi kebocoran pada node, Anda akan melihat lebih banyak proses containerd-shim-runc-v2 di node tersebut daripada jumlah Pod di node tersebut. Anda mungkin juga melihat peningkatan penggunaan memori dan CPU beserta PID tambahan. Untuk mengetahui detailnya, lihat masalah GitHub Memperbaiki shim yang bocor yang disebabkan oleh tekanan IO yang tinggi.

Untuk mengatasi masalah ini, upgrade node Anda ke versi berikut atau yang lebih baru:

• 1.25.15-gke.1040000
• 1.26.10-gke.1030000
• 1.27.6-gke.1513000
• 1.28.3-gke.1061000

Jenis alamat IPv6 diaktifkan pada pod yang menjalankan containerd

Versi GKE yang terpengaruh: 1.18, 1.19, 1.20.0 hingga 1.20.9

Jenis image IPv6 diaktifkan untuk Pod yang berjalan dengan containerd. Gambar dockershim menonaktifkan IPv6 di semua Pod, sedangkan image dalam container tidak. Misalnya, localhost me-resolve ke alamat IPv6 ::1 terlebih dahulu. Hal ini biasanya tidak menjadi masalah, tetapi dapat menyebabkan perilaku yang tidak terduga dalam kasus tertentu.

Solusi

Untuk mengatasi masalah ini, gunakan alamat IPv4 seperti 127.0.0.1 secara eksplisit, atau konfigurasikan aplikasi yang berjalan di Pod agar berfungsi di kedua kelompok alamat.

Penyediaan otomatis node hanya menyediakan node pool Container-Optimized OS dengan Docker

Versi GKE yang terpengaruh: 1.18, 1.19, 1.20.0 hingga 1.20.6-gke.1800

Penyediaan otomatis node memungkinkan kumpulan node penskalaan otomatis dengan jenis image yang didukung apa pun, tetapi hanya dapat membuat kumpulan node baru dengan jenis image Container-Optimized OS dengan Docker.

Solusi

Untuk mengatasi masalah ini, upgrade cluster GKE ke versi 1.20.6-gke.1800 atau yang lebih baru. Dalam versi GKE ini, jenis image default dapat ditetapkan untuk cluster.

Bentrok dengan rentang alamat IP 172.17/16

Versi GKE yang terpengaruh: 1.18.0 hingga 1.18.14

Rentang alamat IP 172.17/16 diisi oleh antarmuka docker0 pada VM node dengan container diaktifkan. Traffic yang mengirim ke atau berasal dari rentang tersebut mungkin tidak dirutekan dengan benar (misalnya, Pod mungkin tidak dapat terhubung ke host yang terhubung dengan VPN dengan alamat IP dalam 172.17/16).

Metrik GPU tidak dikumpulkan

Versi GKE yang terpengaruh: 1.18.0 hingga 1.18.18

Metrik penggunaan GPU tidak dikumpulkan saat menggunakan containerd sebagai runtime pada versi GKE sebelum 1.18.18.

Solusi

Untuk mengatasi masalah ini, upgrade cluster Anda ke GKE versi 1.18.18 atau yang lebih baru.

Gambar dengan config.mediaType yang ditetapkan ke application/octet-stream tidak dapat digunakan di penampung

Versi GKE yang terpengaruh: semua

Image dengan config.mediaType yang disetel ke "application/octet-stream" tidak dapat digunakan di containerd. Untuk mengetahui informasi selengkapnya, lihat Masalah GitHub #4756. Image ini tidak kompatibel dengan spesifikasi Open Container Initiative dan dianggap salah. Image ini berfungsi dengan Docker untuk memberikan kompatibilitas mundur, tetapi image ini tidak didukung di containerd.

Gejala dan diagnosis

Contoh error dalam log node:

Error syncing pod <pod-uid> ("<pod-name>_<namespace>(<pod-uid>)"), skipping: failed to "StartContainer" for "<container-name>" with CreateContainerError: "failed to create containerd container: error unpacking image: failed to extract layer sha256:<some id>: failed to get reader from content store: content digest sha256:<some id>: not found"

Manifes gambar biasanya dapat ditemukan di registry tempat manifes gambar tersebut dihosting. Setelah manifes didapatkan, periksa config.mediaType untuk mengetahui apakah Anda mengalami masalah ini:

"mediaType": "application/octet-stream",

Solusi

Karena komunitas containerd memutuskan untuk tidak mendukung image tersebut, semua versi containerd akan terpengaruh dan perbaikan tidak tersedia. Image container harus dibangun ulang dengan Docker versi 1.11 atau yang lebih baru, dan Anda harus memastikan kolom config.mediaType tidak disetel ke "application/octet-stream".

Konfigurasi CNI tidak diinisialisasi

Versi GKE yang terpengaruh: semua

GKE gagal membuat node selama proses upgrade, pengubahan ukuran, atau tindakan lainnya.

Gejala dan diagnosis

Contoh error di konsol Google Cloud:

Error: "runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized".

Error ini mungkin terjadi dalam situasi berikut:

• Selama proses bootstrap node dalam file log ketika GKE menginstal konfigurasi CLI.
• Sebagai status error node di konsol Google Cloud jika webhook kustom yang mencegat perintah pengontrol DaemonSet untuk membuat Pod mengalami error. Error ini mencegah GKE membuat Pod netd atau calico-node. Jika Pod netd atau calico-node berhasil dimulai sementara error masih berlanjut, hubungi dukungan.

Solusi

Untuk mengatasi masalah ini, coba solusi berikut:

• Tunggu hingga GKE selesai menginstal konfigurasi CNI.
• Hapus semua webhook yang salah dikonfigurasi.
• Konfigurasikan webhook agar mengabaikan Pod sistem.

Langkah selanjutnya

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.