Memigrasikan node ke containerd 2

Cluster Google Kubernetes Engine (GKE) menggunakan image node containerd dengan semua node pekerja yang menjalankan versi 1.24 dan yang lebih baru. Worker node menggunakan versi containerd tertentu, berdasarkan versi GKE:

  • Node yang menjalankan GKE 1.32 atau yang lebih lama, dengan image node containerd, menggunakan containerd versi 1.7 atau yang lebih lama.
  • Node yang menjalankan GKE 1.33 menggunakan containerd 2.0.

Saat node GKE diupgrade dari 1.32 ke 1.33, node akan dimigrasikan dari penggunaan containerd 1.7 ke versi utama baru, containerd 2.0. Anda tidak dapat mengubah versi containerd yang digunakan versi GKE.

Anda dapat melewati membaca halaman ini jika Anda tahu bahwa workload Anda berjalan seperti yang diharapkan di containerd 2.

Cara GKE bertransisi ke containerd 2

Tinjau linimasa berikut untuk memahami cara GKE mentransisikan cluster yang ada untuk menggunakan containerd 2:

  • Dengan versi minor 1.32, GKE menggunakan containerd 1.7. containerd 1.7 menghentikan penggunaan image Docker Schema 1 dan Container Runtime Interface (CRI) v1alpha2 API. Untuk mempelajari fitur lain yang tidak digunakan lagi di versi sebelumnya, lihat Properti config yang tidak digunakan lagi.
  • Dengan versi minor 1.33, GKE menggunakan containerd 2.0, yang menghapus dukungan untuk image Docker Schema 1 dan CRI v1alpha2 API.
  • Properti konfigurasi containerd berikut di plugin CRI tidak digunakan lagi dan akan dihapus di containerd 2.2, dengan versi GKE yang belum diumumkan: registry.auths, registry.configs, registry.mirrors.

Untuk mengetahui perkiraan waktu upgrade otomatis ke versi minor yang lebih baru seperti 1.33, lihat Perkiraan jadwal untuk saluran rilis.

Dampak transisi ke containerd 2

Baca bagian berikut untuk memahami dampak transisi ini ke containerd 2.

Upgrade otomatis dijeda

GKE menjeda upgrade otomatis ke 1.33 saat mendeteksi bahwa cluster menggunakan fitur yang tidak digunakan lagi. Namun, jika node cluster Anda menggunakan fitur ini, sebaiknya buat pengecualian pemeliharaan untuk mencegah upgrade node. Pengecualian pemeliharaan memastikan bahwa node Anda tidak diupgrade jika GKE tidak mendeteksi penggunaan.

Setelah Anda bermigrasi dari penggunaan fitur ini, jika 1.33 adalah target upgrade otomatis untuk node cluster Anda dan tidak ada faktor lain yang memblokir upgrade otomatis, GKE akan melanjutkan upgrade minor otomatis ke 1.33. Untuk node pool cluster Standard, Anda juga dapat mengupgrade node pool secara manual.

Akhir dukungan dan dampak jika gagal bersiap untuk migrasi

GKE menjeda upgrade otomatis hingga akhir dukungan standar. Jika cluster Anda terdaftar di saluran Extended, node Anda dapat tetap menggunakan versi tertentu hingga akhir dukungan yang diperpanjang. Untuk mengetahui detail selengkapnya tentang upgrade node otomatis di akhir dukungan, lihat Upgrade otomatis di akhir dukungan.

Jika Anda tidak melakukan migrasi dari fitur ini, saat 1.32 mencapai akhir dukungan, dan node cluster Anda diupgrade secara otomatis ke 1.33, Anda dapat mengalami masalah berikut pada cluster Anda:

  • Workload yang menggunakan image Docker Schema 1 akan gagal.
  • Aplikasi yang memanggil CRI v1alpha2 API mengalami kegagalan saat memanggil API.

Mengidentifikasi cluster yang terpengaruh

GKE memantau cluster Anda dan menggunakan layanan Recommender untuk memberikan panduan melalui insight dan rekomendasi untuk mengidentifikasi node cluster yang menggunakan fitur yang tidak digunakan lagi ini.

Persyaratan versi

Cluster menerima insight dan rekomendasi ini jika menjalankan versi berikut atau yang lebih baru:

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

Mendapatkan insight dan rekomendasi

Ikuti petunjuk untuk melihat insight dan rekomendasi. Anda bisa mendapatkan insight menggunakan konsol Google Cloud . Anda juga dapat menggunakan Google Cloud CLI atau Recommender API, dengan memfilter menurut subjenis berikut:

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: Image Docker Schema 1
  • DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: CRI v1alpha2 API

Bermigrasi dari fitur yang tidak digunakan lagi

Tinjau konten berikut untuk memahami cara bermigrasi dari fitur yang tidak digunakan lagi dengan containerd 2.

Bermigrasi dari image Docker Schema 1

Identifikasi workload yang menggunakan image yang harus dimigrasikan, lalu migrasikan workload tersebut.

Menemukan gambar yang akan dimigrasikan

Anda dapat menggunakan berbagai alat untuk menemukan gambar yang harus dimigrasikan.

Menggunakan insight dan rekomendasi atau Cloud Logging

Seperti yang dijelaskan di bagian Mengidentifikasi cluster yang terpengaruh, Anda dapat menggunakan insight dan rekomendasi untuk menemukan cluster yang menggunakan image Docker Schema 1 jika cluster Anda menjalankan versi minimum atau yang lebih baru. Selain itu, Anda dapat menggunakan kueri berikut di Cloud Logging untuk memeriksa log containerd guna menemukan image Docker Schema 1 di cluster Anda:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Jika lebih dari 30 hari telah berlalu sejak gambar ditarik, Anda mungkin tidak melihat log untuk gambar.

Menggunakan perintah ctr secara langsung di node

Untuk mengkueri node tertentu guna menampilkan semua image yang tidak dihapus yang ditarik sebagai Schema 1, jalankan perintah berikut di node:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Perintah ini dapat berguna jika, misalnya, Anda memecahkan masalah node tertentu dan Anda tidak melihat entri log di Cloud Logging karena sudah lebih dari 30 hari sejak image ditarik.

Menggunakan alat open source crane

Anda juga dapat menggunakan alat open source seperti crane untuk memeriksa gambar.

Jalankan perintah crane berikut untuk memeriksa versi skema gambar:

crane manifest $tagged_image | jq .schemaVersion

Menyiapkan workload

Untuk menyiapkan workload yang menjalankan image Docker Skema 1, Anda harus memigrasikan workload tersebut ke image Docker Skema 2, atau image Open Container Initiative (OCI). Pertimbangkan opsi berikut untuk melakukan migrasi:

  • Menemukan gambar pengganti: Anda mungkin dapat menemukan gambar open source atau yang disediakan vendor yang tersedia secara publik.
  • Mengonversi gambar yang ada: jika Anda tidak dapat menemukan gambar pengganti, Anda dapat mengonversi gambar Docker Schema 1 yang ada menjadi gambar OCI dengan langkah-langkah berikut:
    1. Tarik image Docker ke dalam containerd, yang secara otomatis mengonversinya menjadi image OCI.
    2. Kirim image OCI baru ke registry Anda.

Bermigrasi dari CRI v1alpha2 API

CRI v1alpha2 API dihapus di Kubernetes 1.26. Anda harus mengidentifikasi workload yang mengakses soket containerd dan mengupdate aplikasi ini untuk menggunakan v1 API.

Mengidentifikasi workload yang berpotensi terpengaruh

Anda dapat menggunakan berbagai teknik untuk mengidentifikasi beban kerja yang mungkin perlu dimigrasikan. Teknik ini dapat menghasilkan positif palsu yang harus Anda selidiki lebih lanjut untuk menentukan apakah tindakan diperlukan atau tidak.

Menggunakan insight dan rekomendasi

Anda dapat menggunakan insight dan rekomendasi untuk menemukan cluster yang menggunakan API v1alpha2 jika cluster Anda menjalankan versi minimum atau yang lebih baru. Untuk mengetahui detail selengkapnya, lihat Mengidentifikasi cluster yang terpengaruh.

Saat melihat insight di konsol Google Cloud , lihat panel sidebar Migrasikan beban kerja Anda dari API v1alpha2 CRI yang tidak digunakan lagi. Tabel Workload yang Perlu Diverifikasi di panel ini mencantumkan workload yang mungkin terpengaruh. Daftar ini mencakup workload apa pun yang tidak dikelola oleh GKE yang memiliki volume hostPath yang berisi jalur soket containerd (misalnya, /var/run/containerd/containerd.sock atau /run/containerd/containerd.sock).

Penting untuk memahami hal berikut:

  • Daftar ini dapat berisi positif palsu. Munculnya beban kerja dalam daftar ini tidak berarti secara pasti bahwa beban kerja tersebut menggunakan API yang tidak digunakan lagi. Hal ini hanya menunjukkan bahwa workload mereferensikan volume hostPath yang mencakup soket containerd. Misalnya, agen pemantauan dapat menyertakan sistem file root (/) node untuk mengumpulkan metrik. Menyertakan sistem file root node secara teknis mencakup jalur soket, tetapi agen metrik mungkin tidak benar-benar memanggil API v1alpha2 CRI.
  • Daftar ini mungkin kosong atau tidak lengkap. Daftar yang kosong atau tidak lengkap dapat terjadi jika workload yang menggunakan API yang tidak digunakan lagi berumur pendek dan tidak berjalan saat GKE melakukan pemeriksaan berkala. Keberadaan rekomendasi itu sendiri berarti penggunaan CRI v1alpha2 API terdeteksi di setidaknya satu node dalam cluster Anda.

Oleh karena itu, sebaiknya lakukan penyelidikan lebih lanjut dengan menggunakan metode berikut untuk mengonfirmasi penggunaan API yang sebenarnya.

Memeriksa workload pihak ketiga yang terpengaruh

Untuk software pihak ketiga yang di-deploy ke cluster Anda, pastikan beban kerja ini tidak menggunakan CRI v1alpha2 API. Anda mungkin perlu menghubungi vendor terkait untuk memverifikasi versi software mereka yang kompatibel.

Menggunakan kubectl

Perintah berikut membantu Anda menemukan beban kerja yang berpotensi terpengaruh dengan mencari beban kerja yang mengakses soket containerd. Tindakan ini menggunakan logika yang serupa dengan yang digunakan untuk tabel Workloads to Verify dalam rekomendasi konsol Google Cloud . API ini menampilkan workload yang tidak dikelola oleh GKE yang memiliki volume hostPath, termasuk jalur soket. Seperti rekomendasi, kueri ini mungkin menampilkan positif palsu atau melewatkan workload berumur pendek.

Jalankan perintah berikut:

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/var", "/var/","/var/run", "/var/run/",
    "/var/run/containerd", "/var/run/containerd/", "/var/run/containerd/containerd.sock",
    "/run", "/run/", "/run/containerd", "/run/containerd/",
    "/run/containerd/containerd.sock"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'
Menggunakan pelacakan eBPF untuk mengidentifikasi pemanggil API

Untuk cara yang lebih pasti dalam mengidentifikasi workload mana yang memanggil CRI v1alpha2 API, Anda dapat men-deploy dua DaemonSet khusus: containerd-socket-tracer dan cri-v1alpha2-api-deprecation-reporter. Alat ini menggunakan Extended Berkeley Packet Filter (eBPF) untuk melacak koneksi ke soket containerd dan mengorelasikan koneksi dengan panggilan API yang benar-benar tidak digunakan lagi:

  • containerd-socket-tracer mencatat setiap proses yang membuka koneksi ke soket containerd, beserta detail Pod dan container.
  • cri-v1alpha2-api-deprecation-reporter mencatat waktu terakhir kali CRI v1alpha2 API dipanggil.

Dengan mengorelasikan stempel waktu dari kedua alat ini, Anda dapat menentukan secara tepat beban kerja yang melakukan panggilan API yang tidak digunakan lagi. Metode ini memberikan tingkat keyakinan yang lebih tinggi daripada hanya memeriksa volume hostPath, karena mengamati koneksi soket dan penggunaan API yang sebenarnya.

Untuk mengetahui petunjuk mendetail tentang cara men-deploy dan menggunakan alat ini, serta cara menafsirkan lognya, lihat Melacak Koneksi Socket containerd.

Jika, setelah menggunakan alat ini, Anda masih tidak dapat mengidentifikasi sumber panggilan API yang tidak digunakan lagi, tetapi rekomendasi tetap aktif, lihat Mendapatkan dukungan.

Setelah mengidentifikasi workload yang menggunakan CRI v1alpha2 API, baik melalui metode sebelumnya atau dengan memeriksa codebase, Anda harus mengupdate kodenya untuk menggunakan v1 API.

Memperbarui kode aplikasi

Untuk mengupdate aplikasi, hapus tempat aplikasi mengimpor library klien k8s.io/cri-api/pkg/apis/runtime/v1alpha2 dan ubah kode untuk menggunakan API versi v1. Langkah ini melibatkan perubahan jalur impor dan memperbarui cara kode Anda memanggil API.

Misalnya, lihat kode golang berikut, yang menggunakan library yang tidak digunakan lagi:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

Di sini, aplikasi mengimpor library v1alpha2 dan menggunakannya untuk mengeluarkan RPC. Jika RPC menggunakan koneksi ke soket containerd, maka aplikasi ini menyebabkan GKE menjeda upgrade otomatis untuk cluster.

Lakukan langkah-langkah berikut untuk menelusuri dan memperbarui kode aplikasi Anda:

  1. Identifikasi aplikasi golang yang bermasalah dengan menjalankan perintah berikut untuk menelusuri jalur impor v1alpha2:

      grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

    Jika output perintah ini menunjukkan bahwa library v1alpha2 digunakan dalam file, Anda harus memperbarui file tersebut.

    Misalnya, ganti kode aplikasi berikut:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

  2. Perbarui kode untuk menggunakan v1:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

Mendapatkan dukungan

Jika Anda telah mengikuti petunjuk untuk Menggunakan rekaman aktivitas eBPF untuk mengidentifikasi pemanggil API, Anda masih tidak dapat menentukan sumber panggilan API yang tidak digunakan lagi, dan rekomendasi tetap aktif, pertimbangkan langkah berikutnya berikut: