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 tambahan, hubungi Cloud Customer Care.

Jalur pemasangan dengan huruf drive sederhana gagal di node pool Windows dengan containerd

Masalah ini telah diatasi di containerd versi 1.6.6 dan yang lebih baru.

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

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

Untuk mengetahui detail selengkapnya, lihat masalah GitHub #6589.

Solusi

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

Image container dengan command line CMD atau ENTRYPOINT pra-escape non-array gagal di node pool Windows dengan containerd

Masalah ini telah diatasi di containerd versi 1.6 dan yang lebih baru.

Cluster GKE yang menjalankan node pool Windows Server yang menggunakan runtime containerd 1.5.X mungkin akan 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 Anda ke versi GKE terbaru yang menggunakan runtime containerd versi 1.6.6 atau yang lebih baru.

Volume image container dengan jalur yang tidak ada atau jalur versi Linux (garis miring) gagal di node pool Windows dengan containerd

Masalah ini telah diatasi di containerd versi 1.6 dan yang lebih baru.

Cluster GKE yang menjalankan node pool Windows Server yang menggunakan runtime containerd 1.5.X mungkin akan 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 mengetahui detail selengkapnya, lihat masalah GitHub #5671.

Solusi

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

/etc/mtab: File atau direktori tersebut tidak ada

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

Untuk mengetahui detail selengkapnya, lihat masalah GitHub #2419.

Solusi

Untuk mengatasi masalah ini, buat symlink /etc/mtab secara manual saat membangun 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 ditarik dengan containerd yang memunculkan pesan error "bukan sebuah direktori". Error ini terjadi jika image dibuat dengan cara khusus: saat perintah sebelumnya menghapus direktori, sedangkan perintah berikutnya membuat ulang file yang sama di direktori tersebut.

Contoh Dockerfile berikut dengan npm yang menggambarkan masalah ini.

RUN npm cache clean --force
RUN npm install

Untuk mengetahui detail selengkapnya, lihat masalah GitHub #4659.

Solusi

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

Jika docker build tidak tersedia sebagai opsi, gabungkan perintahnya 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 ditemukan dan format metriknya berbeda

Versi GKE yang terpengaruh: semua

Endpoint /metrics/cadvisor Kubelet menyediakan metrik Prometheus, seperti yang didokumentasikan di 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 ditemukan di node containerd, berikut contohnya:

    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 serangkaian metrik penampung Prometheus lengkap.

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 pemasangan tidak berfungsi dengan benar setelah runtime container dimulai ulang di GKE Windows

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

Cluster GKE yang menjalankan node pool Windows Server yang menggunakan runtime containerd (versi 1.5.4 dan 1.5.7-gke.0) mungkin dapat bermasalah jika runtime container dimulai ulang secara paksa, menyebabkan operasi pemasangan ke container yang berjalan tidak dapat kembali mengikat IO. Masalah ini tidak akan menyebabkan kegagalan dalam panggilan API, tetapi data tidak akan dikirim atau diterima. Termasuk data untuk memasang dan mencatat CLI dan API ke dalam log 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 node pool yang menggunakan containerd mungkin mengalami masalah kebocoran IP dan menghabiskan semua IP Pod pada node. Pod yang dijadwalkan di node yang terpengaruh akan menampilkan pesan error yang mirip dengan 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 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. Saat pemeriksaan eksekusi yang ditentukan untuk Pod melebihi batas timeoutSeconds Kubernetes yang dideklarasikan, pemeriksaan tersebut akan dianggap sebagai pemeriksaan yang gagal pada image dockershim. Pada image containerd, hasil pemeriksaan yang ditampilkan setelah batas timeoutSeconds yang dideklarasikan akan diabaikan.

Solusi

Di GKE, feature gate ExecProbeTimeout disetel ke false dan tidak dapat diubah. Untuk mengatasi masalah ini, tingkatkan batas timeoutSeconds untuk semua pemeriksaan eksekusi yang terpengaruh atau terapkan fungsi waktu tunggu sebagai bagian dari logika pemeriksaan.

Memecahkan masalah terkait registry pribadi

Bagian ini memberikan informasi pemecahan masalah untuk konfigurasi registry pribadi di containerd.

Penarikan image gagal dengan error x509: sertifikat ditandatangani oleh otoritas yang 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 containerd di node Anda.

Untuk mengatasi masalah ini, coba langkah-langkah berikut:

  1. Pastikan node yang terpengaruh menjalankan Container-Optimized OS. Node Ubuntu dan Windows tidak didukung.
  2. Dalam file konfigurasi, pastikan jalur ke secret di kolom secretURI sudah benar.
  3. Pastikan akun layanan IAM cluster Anda memiliki izin yang benar untuk mengakses secret.
  4. Pastikan 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 containerd, opsi registry tidak aman belum 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:

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

Mengonfigurasi DaemonSet dengan hak istimewa untuk mengubah konfigurasi containerd

Untuk cluster Standard, coba langkah-langkah berikut. Solusi ini tidak tersedia di Autopilot karena penampung dengan hak istimewa memiliki risiko keamanan. Jika lingkungan Anda terekspos ke internet, pertimbangkan toleransi risiko Anda sebelum men-deploy solusi ini. Apa pun kasusnya, sebaiknya konfigurasikan TLS untuk registry pribadi dan gunakan opsi Secret Manager.

  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: registry.k8s.io/startup-script:v2
          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..."
              containerd_config="/etc/containerd/config.toml"
              hostpath=$(sed -nr 's;  config_path = "([-/a-z0-9_.]+)";\1;p' "$containerd_config")
              if [[ -z "$hostpath" ]]; then
                echo "Node uses CRI config model V1 (deprecated), adding mirror under $containerd_config..."
                grep -qxF '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]' "$containerd_config" || \
                  echo -e '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]\n  endpoint = ["http://'$ADDRESS'"]' >> "$containerd_config"
              else
                host_config_dir="$hostpath/$ADDRESS"
                host_config_file="$host_config_dir/hosts.toml"
                echo "Node uses CRI config model V2, adding mirror under $host_config_file..."
                if [[ ! -e "$host_config_file" ]]; then
                  mkdir -p "$host_config_dir"
                  echo -e "server = \"https://$ADDRESS\"\n" > "$host_config_file"
                fi
                echo -e "[host.\"http://$ADDRESS\"]\n  capabilities = [\"pull\", \"resolve\"]\n" >> "$host_config_file"
              fi
              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 yang diteruskan oleh volumeDevices.devicePath, dan membuat setiap perangkat di host tersedia untuk container di bagian /dev.

containerd membocorkan proses shim saat 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 hingga 1.28.3-gke.1061000

Saat node GKE mengalami tekanan I/O, containerd mungkin gagal menghapus proses containerd-shim-runc-v2 saat Pod dihapus, sehingga menyebabkan kebocoran proses. Saat kebocoran terjadi di node, Anda akan melihat lebih banyak proses containerd-shim-runc-v2 di node 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. Image dockershim menonaktifkan IPv6 di semua Pod, sedangkan image containerd tidak melakukannya. Misalnya, localhost di-resolve ke alamat IPv6 ::1 terlebih dahulu. Hal ini biasanya tidak menjadi masalah, tetapi dalam kasus tertentu dapat mengakibatkan perilaku yang tidak terduga.

Solusi

Untuk mengatasi masalah ini, gunakan alamat IPv4 seperti 127.0.0.1 secara eksplisit, atau konfigurasikan aplikasi yang berjalan di Pod agar berfungsi dengan kedua jenis 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 penskalaan otomatis node pool dengan semua jenis image yang didukung, tetapi hanya dapat membuat node pool baru dengan jenis image Container-Optimized OS dengan Docker.

Solusi

Untuk mengatasi masalah ini, upgrade cluster GKE Anda ke versi 1.20.6-gke.1800 atau yang lebih baru. Di 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 digunakan oleh antarmuka docker0 di VM node dengan containerd diaktifkan. Traffic yang dikirim ke atau berasal dari rentang tersebut mungkin tidak dirutekan dengan benar (misalnya, Pod mungkin tidak dapat terhubung ke host yang terhubung ke VPN dengan alamat IP dalam rentang 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 di GKE versi sebelum 1.18.18.

Solusi

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

Image dengan config.mediaType yang disetel ke application/octet-stream tidak dapat digunakan di containerd

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 image biasanya dapat ditemukan di registry tempatnya 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 dengan mengikuti petunjuk berikut:

    1. Cantumkan webhook:

          $ kubectl get mutatingwebhookconfigurations
    $ kubectl get validatingwebhookconfigurations

    2. Hapus webhook yang salah dikonfigurasi:

          kubectl delete mutatingwebhookconfigurations WEBHOOK_NAME
    kubectl delete validatingwebhookconfigurations WEBHOOK_NAME

    Ganti WEBHOOK_NAME dengan nama webhook yang salah dikonfigurasi yang ingin Anda hapus.

  • Konfigurasikan webhook agar mengabaikan Pod sistem.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.